マニュアル: RDBMS

投稿日:

SQLアンチパターン

詳細に書くと良くないので、ざっくりと説明を自分の言葉で記載します。 注意が必要なところは太字にしてます(EAVのような当たり前すぎるものには入れてません)。

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