設計チェックリスト
レビュー時に見落としやすい項目を、正規化・整合性・アンチパターン・運用の観点で確認します。
正規化観点
- 同じ意味のデータが複数テーブルで重複していないか
- 更新時に複数箇所を同時更新する設計になっていないか
- 1NF / 2NF / 3NF の観点で説明できるか
制約観点
- 必須項目に NOT NULL があるか
- 一意項目に UNIQUE があるか
- 参照関係に FK があり、削除時動作が決まっているか
設計アンチパターン
アンチパターン1: 月別を横持ち12カラムで持つ
よくある例として、売上を 1 レコードに 1月売上〜12月売上 で保持する設計があります。
売上集計(
商品ID,
1月売上, 2月売上, 3月売上, ... , 12月売上
)この設計は一見わかりやすいですが、次の問題が起きます。
- 期間の拡張に弱い（13か月目、四半期、週次へ拡張しにくい）
- SQL が複雑化する（合計計算で 12 列を足し合わせる必要がある）
- 正規化に反し、軸（年月）が列名に埋め込まれる
改善例（縦持ち）:
月次売上(
商品ID,
対象年月,
売上金額,
PRIMARY KEY (商品ID, 対象年月)
)縦持ちなら年が増えてもレコード追加だけで済み、集計SQLも単純になります。
アンチパターン2: カンマ区切りで複数値を1列に詰める
タグ='A,B,C' のような保存は検索・更新・整合性の面で不利です。明細テーブルへ分解します。
アンチパターン3: 名称マスタを持たず文字列重複
部門名や商品名を各テーブルに重複保存すると、名称変更時に更新漏れが発生します。ID参照 + マスタ化を基本にします。
「今は楽そう」に見える横持ち・詰め込み設計は、 将来の変更で大きな負債になります。可変軸（年月、タグ、属性）は列ではなく行で表現するのが原則です。
運用観点
- 監査用の作成日・更新日が必要か
- 論理削除フラグの方針はあるか
- バックアップ・復旧時の整合性要件は明確か
レビューで「なぜこの分割なのか」を説明できる設計は、引き継ぎや将来改修で強いです。