必要な正規化・非正規化のバランスが適切に設計されているか？¶
Type: Structure
Category: データ
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
正規化はデータの一貫性を高め、非正規化はパフォーマンスや可読性を向上できるが、設計意図と運用コストのトレードオフでどちらを重視するか選択する
例¶
- 業務的に「分けると面倒」なデータは非正規化して1テーブルにまとめる
- 例えばドキュメントの保存状態をDocumentStatusのようなステータステーブルに保持する一方、UIや検索で頻繁に使われるアクセス頻度の高いカラム情報（例：保存済みかどうか）は正規化を崩してドキュメントテーブルにisSaved:BooleanやsavedAt:DateTimeのように持つ
- データ分析基盤向けに非正規化ビューや集計テーブルを作成する
よくある失敗例¶
- 正規化しすぎてJOINが複雑・パフォーマンス劣化
- 非正規化しすぎて同じ情報を複数テーブルで保持し、整合性が壊れる
- 画面描画時に大量のJOINが必要になり、UIレスポンスが低下
FAQ¶
Q. 正規化・非正規化の判断はどうする？
A. 更新頻度・表示要件・参照方法などを元にケースバイケースで判断。基本的にデータ不整合のリスクを下げる方を重視するのが無難
Q. 中長期的には常に正解化して分割した方が柔軟では？
A. 正規化しすぎると実装やUI側で無駄な結合が増えがち。将来の柔軟性より現在の業務要件と複雑さを重視して正規化・非正規化のバランスを考えるのが無難