AIでデータベースを設計する
「何を保存するか」をAIでテーブルにする。カラム・関連・インデックス、そして自分を追い込まない設計順。
学習ルートCRMルート
ひとことで言うと
データベース設計＝まず何を保存し、どうつながるかを決める。それからAIにテーブル化させる。
作れるもの
カラム・型・関連・インデックスが明確なテーブル草案。そのままAIに渡してマイグレーションを生成できる。
テーブルに触る前に「名詞」を並べる
いちばん簡単な始め方：プロダクトを一文で説明し、その中の名詞に丸をつけます。「ユーザーが注文して商品を買う」なら、名詞はユーザー・注文・商品。この3つがたいてい3つのテーブルになります。
先に名詞、次にカラム。逆順（先にカラム）だと、設計するほど散らかりがちです。
先に答える3つの問い
- 各モノにどんなカラムと型が必要か？ ユーザーは email（文字列）と作成日時（タイムスタンプ）。注文は金額（数値）と状態（文字列）。
- 何と何が関連するか？ 1人のユーザーは多数の注文を持つ（1対多）。1つの注文は多数の商品を含む（多対多。中間テーブルが必要）。
- よく検索されるカラムは？ email でユーザーをよく探すなら、email にインデックスを張ると検索が速いままです。
AIにはこう言う
名詞リスト・カラム・関連を整理し、AIにスキーマとマイグレーションを生成させます。次を明示的に要求しましょう。
- どのテーブルにも
id・created_at・updated_atを持たせ、時刻は UTC で保存。 - 正しい型を使う（金額を文字列に、真偽値を "0"/"1" の文字列にしない）。
- 関連は外部キーで表し、検索するカラムにインデックスを張る。
- マイグレーションはロールバック可能に（up があれば down も）。
例：シンプルな注文システム
1人のユーザーは多数の注文を持ち、1つの注文は複数の「注文明細」で構成され、各明細は1つの商品を指します。中央の ORDER_ITEM が「多対多」を扱う中間テーブルです。
初心者がはまる落とし穴
- 巨大な1テーブルに全部詰める：カラムが爆発し、1か所の変更が全体に波及。必要なら分割。
- すべて文字列型：合計・並べ替え・大小比較が後でつらくなります。
- 時刻をUTCで保存しない：タイムゾーンをまたぐとバグ確定。表示時にローカルへ変換すればよい。
- 最初から過剰設計：使うものを作り、必要になってから足す。YAGNI。
次のステップ
- 概念を固める：データベース Database
- 実際に使うデータベースを選ぶ：データベース選び：D1 vs Postgres vs SQLite
よくある質問
データベース設計を完全にAIに任せ、自分は何も考えなくてよい？
おすすめしません。少なくとも「何を保存するか（名詞）」「どう関連するか」は自分で並べるべきで、それはあなたにしか分からない業務知識です。それを明確にしてAIにスキーマを生成させれば製品に合います。さもないとAIは一般的な推測しかできず、後の変更がつらくなります。
最初からデータベースを完璧に設計しないといけない？
いいえ。実際に使うカラムと関連だけ作り（YAGNI）、必要になったら足します。ただし「型・形」は最初に正しくする価値があります。金額は数値、時刻はUTC、よく検索するカラムにインデックス——これらは後の変更コストが高めです。
参考資料
- PostgreSQL Documentation — PostgreSQL Global Development Group
- SQLite Documentation — SQLite
CRMルート の次のステップ: 認証 →