「達人に学ぶDB設計徹底指南書」を読んだ
先日読んだSQL徹底指南書の姉妹本ということで、ミック氏の「達人に学ぶDB設計徹底指南書」を読んでみた。
どんな本か
2012年3月15日発行。翔泳社。著者はSQLに関する著書を数々出版しているミック氏。脱初級者を目指す技術者向けに、データベースの論理設計と物理設計を解説する実践書。「達人に学ぶSQL徹底指南書」の後継にあたる。
所感
全体的に説明がわかりやすく、良書と言われているのが納得できた。2〜3年目くらいの小規模なテーブル設計に手を出し始めたソフトウェアエンジニアが読むと成長の糧になりそう。半分くらいはIPAのデータベーススペシャリスト試験の範囲と被っている印象なので、併せて勉強するとよりデータベースの基礎体力に繋がるかもしれない。
私自身がまさにそうかもしれないが、『若手エンジニアに自信を持ってDB設計を教えられないな』と感じている中堅の方にとって、教える際の良いヒントが得られるのではないかと思った。
自分用メモ
サイジングは速さと多さ
データベースのサイジングはキャパシティとパフォーマンスの両観点から考える。「どれだけ多いか」「どれだけ速いか」の2つだけ。
関係と表の違い
関係と表は似ているがイコールではない。
- 関係には重複するレコードは存在してはならないが、表には存在できる
- 関係のレコードは順序を持たないが、表の行は順序付けられている
- 関係の列は左右の順序を持たないが、表の列は順序付けられている
JOINなどでテーブルとテーブルを関係させるから関係データベースだと思っていたが、全く違っていたらしい。
ER図の種類
ER図2大巨頭。鳥の足っぽいIE法と、IDEF1X。カーディナリティの表記方法が違う。IDEF1Xの方が表現力が高い。
正規化と非正規化
- 正規形は検索パフォーマンスでは不利
- 正規形は更新のパフォーマンスでは有利
- 非正規形にすることで結合をせずにデータ取得が行える
- 原則は第三正規形で、やむを得ない場合に非正規化を検討する
アクセスパスとカーナビの例
SQLは『どんなデータが欲しいか』を書く言語であって、『どのようにデータを取得するか』は書かれない。どのように取得するかはDBMSが考えること。
これはカーナビと人間の関係に似ている。人間はカーナビに目的地を入力するが、どの経路を通るかはカーナビに任せる。
B+木が優等生
- ずば抜けて得意な分野はない
- 弱点が少ないオールラウンダー
- 平衡木。どの葉もルートから同じ距離で計算量が安定している(O(log n))
- 構築時にキー値をソートするので、<や>の大小比較検索にも強い
- 否定条件には弱い
インデックス設計
- 大規模なテーブルに作る
- カーディナリティの高い列に作る
- 目安は、特定のキーを指定した時に全体の5%程度に絞り込めること
- 平均的に分散しているのがベスト
- 複合キーの場合は複合後の絞り込み数を元に考える
- WHERE句の選択条件、結合条件に使われる列に作る
- レコード数1万件以下はインデックスの効果が期待できない
- 列の値が頻繁に更新されるものはインデックスに向かない
アンチパターン集
- 配列型による非スカラ値
- そんなのあったんだ
- ダブルミーニング
- クレイジー
- 単一参照テーブル
- 正気の沙汰でない
- テーブルの水平分割
- シャーディングという名前で地位を確立しつつある
- テーブルの垂直分割
駄目な設計が生まれる理由は「何も考えていない」ことによるもの
さいごに。本書を読んでいてこの一文が強く印象に残った。
非正規化は、様々なトレードオフを考慮しながら慎重に実施する必要のある、難しい仕事です。人々は一般にそのような仕事を嫌がります。しかし、それこそがエンジニアの本務だと著者は考えています。
データベースはアプリケーションのコードと比べて設計の変更が難しく、つい目をそらしてしまいがちな領域。自分にも思い当たる点がいくつもある。その一方で改善の伸びしろが大きい領域でもあるので、できるだけ逃げずに改善を進めていきたいと思った次第。