SQLアンチパターン
詳細に書くと良くないので、ざっくりと説明を自分の言葉で記載します。 注意が必要なところは太字にしてます(EAVのような当たり前すぎるものには入れてません)。
- ジェイウォーク(信号無視)
- 1:nとかn:mの場合ににカンマ区切りで入れてしまう。サボらずにちゃんとテーブルを作ろう。
- ナイーブツリー(素朴な木)
- 階層がある場合に「親子関係」だけで管理するもの。
- 解決策がいろいろあってややこしい。
- IDリクワイアド(とりあえずID)
- なんでもかんでもPKとしてIDをつける。
- 例外: フレームワークのORMを使っている場合
- フレームワークの便利さとのトレードオフになるが、少なくともUNIQUE制約を付ける
- キーレスエントリ(外部キー嫌い)
- 外部キーはポカヨケ。
- 解決案としてカスケード更新が挙げられている
- EAV(エンティティ・アトリビュート・バリュー)
- ありがち。EAVを使う誘惑に負けないことが重要。
- 例外: スキーマレスなもの→ただしJSON型とかを使ったほうがよい
- 解決案で挙げられているものは正直微妙感・・・
- ポリモーフィック関連
- 親が2つあるときに「どれが親か」という列と「親のID」を格納する。
- 親が2つあるので外部キーとして設定できない
- 解決案は書籍参照(いまいち読めてない)
- マルチカラムアトリビュート(複数列属性)
- ジェイウォークと似たようなタイプで、複数列で対応するもの。
- 例外: 論理的に違う列の場合
- BTSでの作成者、担当者など。ただし複数人には対応できないので本当に1人なのか考える。
- 解決案: 従属テーブルを作る
- メタデータトリブル(メタデータ大増殖)
- テーブル名に情報を入れる(年月とか)。自分としては信じられないけど。
- 例外: 「アーカイブ用のテーブル」程度
- 解決案
PARTITION BYを使う(知らない・・・)- BLOBとかを使う場合はテーブルを分割
- ラウンディングエラー(丸め誤差)
- 正確なデータが必要なときにFLOATを使う
- 解決策: NUMERIC
- サーティワンフレーバー(31のフレーバー)
- 特定の値しか入らないことを保証するためにCHECK制約を使う
- 例外: 値が変わらないとき(明らかにon/offしかないよとか)
- プログラミングでのbooleanとStringの扱いと同じだと思った。
- 解決案: テーブルを分けてFKで制約を指定
- ファントムファイル(幻のファイル)
- 画像ファイルを物理ファイルとして格納する
- 最近はS3に格納するので、アンチパターンとは言えないと思う(容量とのトレードオフ)。ただデメリットの考慮は必要。
- インデックスショットガン(闇雲インデックス)
- なんでもかんでもインデックスを作成
- 闇雲でなくても「将来必要かも」で付けるのはありそう。。。
- フィア・オブ・ジ・アンノウン(恐怖のunknown)
- NULLの扱い。NULL=わかりません。詳細はあとで見直す必要あり。
- アンビギュアスグループ(曖昧なグループ)
- ランダムセレクション
- プアマンズ・サーチエンジン(貧者のサーチエンジン)
- スパゲッティクエリ
- インプリシットカラム(暗黙の列)
- リーダブルパスワード(読み取り可能パスワード)
- SQLインジェクション
- シュードキー・ニートフリーク(疑似キー潔癖症)
- シー・ノー・エビル(臭いものに蓋)
- ディプロマティック・イミュニティ(外交特権)
- マジックビーンズ(魔法の豆)
- 砂の城