いつ読むか?

  • テーブルの正規化を考えるとき
  • データモデリングをするとき

読書メモ

核心メッセージ

「カラム追加ではなくテーブル追加」で変化に対応する

基本原則

  • Simple vs Easy: 短期的に楽な実装ではなく、責務を小さく分割したシンプルな設計を選ぶ
  • 事実のみを保存: 冗長性と NULL を避ける
  • ライフサイクルの異なるものは分離: 別テーブルに切り出す

実践テクニック

  • ユーザーに認証方法を追加する場合 → users にカラム追加ではなく user_login_line 等の別テーブルを作成
  • 「ユーザー」が複数の役割を持つ場合 → type カラムではなく役割ごとにテーブル分離
  • 複数の決済方法を扱う場合 → 抽象化レイヤー(user_default_payment)で参照

活用シーン

  • 頻繁なリリースを行うチーム
  • 要件変更が多いプロダクト
  • DB マイグレーションが CI/CD のボトルネックになっている場合