■ 1. 発表の前提と問題意識
- 時代は大AI（Agent）時代であり、テーブル設計もAIに代替されるかという問いがある
- 結論として、テーブル設計はAIに代替されない
- AIは労力を代替できるが、能力（設計力）は代替できない（@t_wada）
- AIは設計のサポートをしてくれるが、設計の判断は人間が行うしかない
- データベースの寿命はアプリケーションよりも長く、だからこそデータベース設計が重要
■ 2. データベースが変化に弱い理由
- 変化に弱い根本的な原因:
- DELETEやUPDATEによりcommitされたデータは元に戻せない
- カラム追加時には過去データへの対応が必要
- INSERTなど前後のアプリケーションとの互換性を考慮する必要がある
- 一度作ったテーブルやデータを削除して良いか判断が難しい
- サービスが成長するにつれ自然とデータベースも肥大化する
- 肥大化の結果として生じる問題:
- 本番環境へのALTER実行でロックが発生しサービスが停止する
- 特定カラムを確認するif文の列挙が複雑化する
- SELECTするまで結果がわからない
- テーブルの変更が怖くなる
- ビジネスは常に変化するため仕様変更は必然的に発生し続ける
■ 3. 設計上の問題の具体例: usersテーブルへのLINE認証追加
- 初期のusersテーブル構成: name、birthday、email、hashed_password
- LINE認証を追加する場合の問題:
- usersテーブルにカラム追加する場合:
- emailとpasswordが必須のため、LINE認証で登録してもemailとpasswordの入力が必要
- ユーザの手間が減らず、むしろ増える
- LINE認証情報を別テーブルにした場合も同じ問題が生じる:
- emailとpasswordをNULL許可にする必要がある
- NULLを許可するとemailのUNIQUE制約が機能しなくなる
- 機能開発のためのテーブル変更がビジネス側に不要な制約を生み出す
- 仕様追加が積み重なると、将来を見据えたテーブルの修正なしには次の仕様追加に耐えられなくなる
- 対応策の方針:
- データベースに状態を持たせない
- データベースには事実のみを保存する
- ビジネスロジックはアプリケーション側で担保する
■ 4. 正規化とSimple is Beautiful
- 正規化の基本方針:
- 事実だけを保存する
- 重複がない
- 不整合がない
- NULLがない
- 情報と事実（データ）は異なる:
- 生年月日は事実
- 年齢はそのタイミングの情報（派生値）
- 正規化はUnixの哲学とも通じる:
- Small is beautiful（小さいものは美しい）
- Make each program do one thing well（1つのプログラムには1つのことをうまくやらせる）
- テーブル設計への応用:
- 1テーブル、1責務を原則とする
- SimpleとEasyは異なる概念であり、Simpleを目指す
- SimpleとEasyは両立可能であり、質とスピードも両立できる
- usersテーブル分割の実例:
- emailは認証情報以外の属性も持つため（複数emailを持つ可能性など）、passwordと別テーブルに分ける
- 分割後の構成: users、user_email、user_personal_information、user_login_hashed_password
- この設計によりuser_login_lineテーブルを追加するだけで新たなログイン方式に対応できる
- イミュータブルデータモデリングを活用してUPDATE操作を減らす
- テーブルがSimpleであるほど変化に強くなる
■ 5. AIとの設計の歩み方
- AIにテーブル設計を一任することは上手くいかない
- LLMの特性と限界:
- LLMは単語に対してありそうな文言を回答するが、設計の背景を知らない
- それっぽいテーブルは生成できるが、良くある駄目なパターンを回答しやすい
- 世の中のOSSには EasyでDirtyな設計が多く（例: WordPressやRedmineのEAV）、それらを学習している
- 機能単位などの大きな単位でAIに任せるのはプロトタイプ以外では悪手
- AIの学習モードの限界:
- AIはシングルループ学習（実行結果をもとに行動を変える）にとどまる
- 人間が行うダブルループ学習（結果から前提を見直して根本から変更する）はできない
- 要求は物理世界にあり、前提の見直しと要求変更は人間の仕事（しばらくは）
- AIの適切な活用方法:
- データモデリング自体は人間が行い、サポートとしてAIを活用する
- MarkdownからER図やDDLを生成させる
- DDLからテストデータを生成させる
- DDLから想定するユースケースを洗い出し、ユースケース別のSELECTクエリを生成させる
- PKの設定漏れやカラム名のタイポなどをレビューさせる
- JSONやCSVから必要なエンティティを取り出す
■ 6. おわりに
- 今こだわり抜いた設計が未来の自分を救う
- 仕様を満たすコードではなく、要求を満たすコードを書くことが重要
- 要件に合わせて設計するのではなく、要求に合わせて要件を整理することが重要
- データモデリングのスキルは寿命が長く、複利で効く能力
- データベース設計はしばらくAIに代替できる仕事ではなく、AIには労力のサポートをさせる位置づけが適切
- データベースのリファクタリングで最大の鬼門は仕様であり、ビジネス理解と調整が最も効果的
- 推薦書籍:
- 「SQL実践入門」（ミック著）: SQLの基礎本
- 「達人に学ぶDB設計 徹底指南書」（ミック著）: DB設計の基礎本
- 「SQLアンチパターン 第2版」（Bill Karwin著、t_wada監訳）: 重要なアンチパターンを網羅
- 「失敗から学ぶRDBの正しい歩き方」（曽根 壮大著）: PostgreSQL & MySQL対応
- データモデリングはスキルであるため、正しく学べば身につけることができる
- Simple is Beautiful: 常に追求した者だけが辿り着ける境地