「SQLアンチパターン」(データベース論理設計のアンチパターン）
勉強記録
「SQLアンチパターン」のⅠ部 データベース論理設計のアンチパターンを読んだので、学んだことをまとめました。
<1章> ジェイウォーク（信号無視)
1つの列にカンマ区切りで複数のデータを入れること。
（なぜアンチパターンなのか）
正しいデータが入っているのか分からない
効率的な検索ができない
更新が大変
リストの長さの制限がある
（アンチパターン使ってもいいとき）
パフォーマンス向上のために非正規化せざるを得ないとき。
（解決方法）
交差テーブルを作成する。
<2章> ナイーブツリー（素朴な木）
直近の親のみを参照するツリー構造。
（なぜアンチパターンなのか）
処理が遅くなる
SQL文書くのが大変
削除が難しい
（アンチパターンを使ってもいいとき）
アプリケーションとマッチするとき
（解決方法）
代替ツリーモデルを使う
・経路列挙モデル →LIKE検索で検索しやすい
・入れ子集合モデル
・閉包テーブルモデル
<3章> ID リクワイアド（とりあえずID)
行の重複を避けるために、とりあえず「id」をつけること。
（なぜアンチパターンなのか）
重複行を許可してしまう
キーの意味がわかりにくくなる
（アンチパターンを使ってもいいとき）
フレームワークやORMでそうせざるを得ないとき。
(解決方法）
複合主キーの活用
<4章> キーレスエントリ（外部キー嫌い)
外部キー制約を使用しないこと
（なぜアンチパターンなのか）
制約がつかないから、人やプログラミングのミスで変なデータが入ってしまう
（アンチパターンを使ってもいいとき）
外部キー制約が使えない場合
垂直分割しているとき
→垂直分割するとDBが異なるので、外部キー制約が使えない
（解決方法）
外部キー制約を使おう！
<5章> EAV（エンティティ・アトリビュート・バリュー）
汎用的な属性テーブルを作ること（なんでも入れていいテーブルを作ってしまうこと）
（なぜアンチパターンなのか）
データの整合性が確保できない
検索が難しい
（アンチパターンを使ってもいいとき）
EAVを正当化する理由はない！
(解決方法）
サブタイプのモデリング （あとで勉強！）
ちゃんとテーブル定義をしよう！
<6章> ポリモーフィック関連
1つのテーブルを複数のテーブルに関連させるような設計のこと
（なぜアンチパターンなのか）
外部キー制約が使えない
（アンチパターンを使ってもいいとき）
フレームワークやORMでそうせざるを得ないとき。
（解決方法）
交差テーブルの作成
共通の親テーブルの作成
<7章> マルチカラムアトリビュート（複数列属性）
属性の数だけカラムを事前に定義すること
（なぜアンチパターンなのか）
値の検索が難しい
値の追加と削除が難しい
複数の列に同じ値を入れてしまう可能性がある
列数が足りなくなった時に大変
（アンチパターン使ってもいいとき）
関連付けられる属性の種類が限定できる場合
（解決方法）
従属テーブルをつくる（中間テーブルを作ってもよい）
<8章>メタデータトリブル（メタデータ大増殖）
スケーラビリティを高めたいときに、テーブルや列を分割して1テーブルあたりのデータを少なくすること
※スケーラビリティを高めたいとは、サーバーを増やしてパフォーマンスを上げたいということ
（なぜアンチパターンなのか）
テーブルが増えて大変
テーブルの整合性がとれない
テーブルをまたいだクエリを実行しなければならなくなる
ユニークキーの保証が大変
（アンチパターンを使ってもいいとき）
常に最新のデータだけを欲しいとき
過去データの参照が年１とかのレベルで極端に少ないとき
（解決方法）
パーティショニングと正規化
※パーティショニングとは、テーブルは１つだけど中をブロックで分けること（RDBMSの機能としてある）
シャーディングのように物理分割ではなく、論理分割である
