[B! SQL] akitsukadaのブックマーク

NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 － Publickey

NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？」で紹介しています。講演内容をダイジェストにしまし

akitsukada 2015/02/10

いいと思うけど PostgreSQL 選定の理由や判断材料なんかも知りたいな？ > "当たり前にPostgreSQLを使う現在でも、シビアな条件で使おうとするとまだまだ課題があります"

リンク

SQLアンチパターン「健忘症的サロゲートキー」の提案 - 極北データモデリング

SQLアンチパターン作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人クリック: 698回この商品を含むブログ (46件) を見る本書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転

akitsukada 2013/03/21

"過去の受注の商品コードを復元できない"のが困るんだったら受注明細には事実として受注時点での商品コードを残しておくべきでないかな／「トランザクション上の自然キーは過去の事実だから云々」がそれかな

SQL
db

リンク

SQLアンチパターン

本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。本書への称賛の声監訳者まえがきはじめに I部データベース論

akitsukada 2013/01/15

買った

database
SQL

リンク

Ruby on Railsのfind_by_*メソッドにSQLインジェクション脆弱性(CVE-2012-5664) | 徳丸浩の日記

Ruby on Rails(3.2.9, 3.1.8, 3.0.17以前)のfind_by_*メソッドにSQLインジェクション脆弱性が見つかりました(CVE-2012-5664)。このエントリではその概要と対策について説明します。概要 Ruby on Railsのfind_by_*メソッドの引数としてハッシュを指定することで、任意のSELECT文を実行できる脆弱性があります。検証 Ruby on Rails3.2.9の環境を用意して、以下の2つのモデルを用意しました。 $ rails g scaffold user name:string em ail:string $ rails g scaffold book author:string title:string モデルUserは個人情報を保持しており、自分自身の情報のみが閲覧できるという想定です。モデルBookは書誌データベースであ

akitsukada 2013/01/04

リンク

アプリ開発者よりのDB勉強会をやりたい、というかやる - 分け入ってもコード

結論 SQLがどーのデータの持ち方がこーのというアプリ開発側の話題がメインのDB勉強会をやりたいからやるよという話以下補足コンテンツアプリ開発者がDBを握らなければならない時代 DBを握るということ勉強会についてアプリ開発者がDBを握らなければならない時代データ爆発の時代データ爆発の時代がくると言われて久しいです。扱うデータの量が増えてきているだけでなく、データの構造も多種多様になってきていると感じています。これまではOne Size Fits AllでRDBが対応してきたのが、増加し複雑化していくデータにRDBのみでは対応しきれなくなってきている為にNoSQLのようなプロダクトが盛んに開発され利用されています。アプリ開発者としてやるべきことそういった時代を迎えるにあたって、アプリ開発者は何も備えなくていいんでしょうか？DBはインフラ/サーバーエンジニアのもの？僕は「D

akitsukada 2011/06/27

参加したいです

リンク

@sikushima 氏のDB語り:適材適所/ストアドプロシージャ/ORM編

SQLの苦手を克服する本(技術評論社)/生島勘富 @Sikushima ぜひ、こちら http://bit.ly/9wrdmq も、ご覧下さい。 QT @ryan5500: マーティンファウラーの記事読んでる．これすごいなー．ドメインモデルが一番わかりやすいけど，その一部を差し替えて複雑なSQLにするだけでこんなにパフォーマンスあがるのか． SQLの苦手を克服する本(技術評論社)/生島勘富 @Sikushima マーティンさんの http://bit.ly/12p9WO のパフォーマンスの差は私の経験則ではもっと大きな差になると思う。これ、多分、APとDBが同じマシンでやってるのじゃないかな。パフォーマンスの差はデータ量にもよるから何とも言えないけどね。 SQLの苦手を克服する本(技術評論社)/生島勘富 @Sikushima DBへのアクセスをストアドプロシージャでというと、ビューで