「SQLアンチパターン」を避けるためのチェックリスト（サマリー版）

　これまで「SQLアンチパターン」本のまとめを書いてきました。

「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho

「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho

「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho

「SQLアンチパターン」を避けるためのチェックリスト④（アプリケーション設計編） - log4ketancho

この記事は、自分用のチェックリストとして、これまでの記事をサマライズしたものになります。本にこのチェックリストが書かれているわけではなく、個人的に解釈したものになりますが、もしよろしければ DB 設計の一助にしていただければ幸いです。

SQLアンチパターン

DB 論理設計編

カンマ区切りフォーマットのリストを格納していないか？
3世代以上の階層があるデータ構造を扱う場合に、直接の親子関係のみを参照する形にしていないか？
主キー名を何も考えず `id` にしていないか？
必要な外部キーは設定しているか？
柔軟に「列」を増やすために、Attribute とその Value を表す列を作成してしまっていないか？
複数の異なるテーブルに紐付く可能性があるテーブルを作成する場合に、xx_type といった列を見て紐付く先のテーブルを判断する設計になっていないか？
1対Nで保持したいデータがある場合に、列を row1、row2、、、rowN のように増殖させる設計にしていないか？
時間経過によってテーブルや列を増やすことを前提とした設計になっていないか？

DB 物理設計編

精度が求められる値の型に FLOAT 型を採用していないか
CHECK や ENUM などの列定義の制約で、列に入る値を限定してしまっていないか
「何が何でもファイルはDBの外側で保持しなくちゃ！」と考えていないか
インデックスは正しく定義されているか、あるいは、インデックスを活かした検索をしているか

SQLクエリ設計編

NULLを一般値として使用していないか？一般値をNULLに相当するものとして扱っていないか？
GROUP BY句を使う場合、単一値の原則を満たすクエリとなっているか
ランダムにレコードを取得する場合、性能劣化しない方式を採用できているか
データ量が増える可能性のあるテーブルに、あいまい検索していないか
複雑すぎるクエリを作っていないか
必要のない列まで SELECT していないか

アプリケーション設計編

パスワードを平文でテーブルに格納していないか
動的に SQL 文を作成するときに SQL インジェクションへの対策をしているか
連番主キーの欠番を頑張って埋めようとしていないか
DB接続している部分で例外処理しないプログラムはないか
バージョン管理されてない DB 関連リソースはないか
モデルがアクティブレコード化していないか
発生しうる問題やそれに対する対応はまとまっているか

参考記事

www.ketancho.net

www.ketancho.net

www.ketancho.net

www.ketancho.net

まとめ

　これまでの記事にも書きましたが、この本はエンジニアとしての血肉本だと思います。この本のパターンを抑えておけば常に100点が取れるわけではないですが、プロダクトに関わる全エンジニアがこの本を理解した上で設計を進めれば、質の高い議論ができ、致命的な手戻りを減らすことができるのではないかと思っています。ぜひ読んでみてはいかがでしょうか？:)

SQLアンチパターン