用 AI 設計資料庫
用 AI 把「要存什麼」變成資料表：欄位、關聯、索引，以及不會一開始就把自己搞死的設計順序。
屬於路線CRM 路線
一句話解釋
資料庫設計＝先想清楚要存哪些東西、彼此怎麼連，再讓 AI 把欄位與關聯寫成資料表。
你會做出什麼
一份說得清楚的資料表草稿（欄位、型別、關聯、索引），可以直接交給 AI 產生 migration。
先別碰資料表，先列「名詞」
設計資料庫最簡單的起手式：把你的產品用一句話描述，圈出裡面的名詞。例如「使用者可以下訂單買商品」，名詞是使用者、訂單、商品——這三個多半就是你的三張表。
先列名詞，再想欄位。順序反過來（先想欄位）很容易越設計越亂。
三個一定要先想的問題
- 每個東西要存哪些欄位、什麼型別？ 使用者有 email（文字）、建立時間（時間）；訂單有金額（數字）、狀態（文字）。
- 誰跟誰有關聯？ 一個使用者有很多訂單（一對多）；一張訂單有很多項商品（多對多，需要一張中間表）。
- 哪些欄位常被拿來查？ 常用 email 找使用者，就在 email 上建索引，查詢才會快。
跟 AI 這樣說
把上面的名詞清單、欄位、關聯整理好，再請 AI 產生 schema 與 migration，並明確要求：
- 每張表都要有
id、created_at、updated_at，時間一律存 UTC。 - 用正確的型別（金額別用文字、布林別用 0/1 字串）。
- 關聯用外鍵表達，常查的欄位加索引。
- migration 要能回滾（有 up 就要有 down）。
範例：一個簡單的訂單系統
一個使用者有多張訂單；一張訂單由多個「訂單項目」組成；每個項目對應一個商品。中間的 ORDER_ITEM 就是處理「多對多」的中間表。
新手最常踩的坑
- 一張大表塞所有東西：欄位爆炸、改一個地方影響全部。該拆就拆。
- 全部用文字型別：之後要算總額、排序、比大小都會很痛。
- 時間不存 UTC：跨時區一定出錯，顯示時再轉當地時間就好。
- 一開始就過度設計：先做會用到的，需要再加。YAGNI。
下一步
- 補觀念：資料庫 Database
- 選一個真的要用的資料庫：選資料庫：D1 vs Postgres vs SQLite
常見問題
我可以完全叫 AI 設計資料庫，自己什麼都不想嗎？
不建議。你至少要先列出「要存哪些東西（名詞）、彼此怎麼關聯」，這是只有你最懂的業務知識。把這些講清楚再交給 AI 產 schema，結果才會貼合你的產品；否則 AI 只能用通用猜測，之後改起來很痛。
一開始就要把資料庫設計到完美嗎？
不用。先做會用到的欄位與關聯就好（YAGNI），需要時再加。但「量級」值得一開始就想對——例如金額用數字、時間存 UTC、常查的欄位加索引，這些之後再改成本較高。
參考來源
- PostgreSQL Documentation — PostgreSQL Global Development Group
- SQLite Documentation — SQLite
CRM 路線 的下一步: 身分驗證 →