什麼是資料庫？為應用程式建置者寫的指南
資料庫是應用程式用來儲存與讀取資訊的一個有組織的儲存區，例如它的使用者、訂單、預約與訊息。與只存在瀏覽器分頁中的資訊不同，資料庫中的資料在重新整理或重新啟動後依然存在，而且所有使用這個應用程式的人看到的都是相同的紀錄。大多數資料庫會把資料組織成資料表，很像試算表的工作表，但有嚴格的規則來維持資料的一致性。
為什麼使用 AI 建置時這很重要
使用 AI 建置時最常見的意外，是應用程式看起來已經完成，卻什麼都不記得。你新增了一位客戶，重新整理頁面，它就不見了。這通常代表應用程式把資料保存在瀏覽器的記憶體中，而不是資料庫裡。
資料庫也是許多重要決定的所在，不管你是否意識到：
- 你記錄什麼。 如果你沒有儲存預約的狀態，就無法顯示哪些預約已取消。
- 事物如何連結。 一位客戶能否有多筆預約，或一筆預約能否包含多項服務，決定了整個應用程式的形狀。
- 誰能看到什麼。 大多數隱私問題，都出在使用者能讀取哪些紀錄上。
你不需要自己設計資料庫，但了解基本概念，能讓你清楚描述你的資料，並及早發現問題。
日常生活的比喻
想像一間管理良好的小型辦公室裡的檔案櫃。
每個抽屜裝一種東西：一個抽屜放客戶，一個放預約，一個放發票。每個抽屜裡，每個資料夾都遵循相同的格式，並填寫相同的欄位。每個資料夾都有唯一的參考編號，而當一張發票屬於某位客戶時，發票資料夾會記下那位客戶的編號，而不是把整份客戶檔案影印一份。
這就是關聯式資料庫。抽屜是資料表，資料夾是資料列，欄位是資料行，參考編號是主鍵，而指向另一個資料夾的註記就是外鍵。一位好的辦公室主管還會執行規則，例如不能沒有日期的預約、不能有兩位同編號的客戶，資料庫也是如此。
實例：沙龍預約應用程式
假設你請 AI 替一間美髮沙龍建一個預約網站。合理的資料庫會有四張資料表。
services（服務）
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | 剪髮 | 45 | 40.00 |
| 2 | 染髮 | 90 | 95.00 |
staff（員工）
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers（客戶）
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings（預約）
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
看看 bookings 這張資料表。它沒有把 Lena 的姓名和電話複製到每一筆預約中，而是儲存 customer_id = 101。如果 Lena 更改電話號碼，只需在一個地方更新，每筆預約就都會顯示新號碼。這就是關聯式資料庫的核心概念：每個事實只存一次，然後用連結去引用它。
同樣的結構也能回答實用的問題：
- 「Omar 週五哪些時段是空的？」——查看 Omar 當天的預約。
- 「本月染髮服務賺了多少？」——把預約與服務連接起來，並加總價格。
- 「哪些客戶九十天內沒有預約？」——比對客戶與他們最近的一筆預約。
常用術語說明
| 術語 | 意義 |
|---|---|
| 資料表（Table） | 同一類紀錄的集合，例如客戶或預約。 |
| 資料列 / 紀錄（Row / record） | 資料表中的一項，例如一位客戶、一筆預約。 |
| 資料行 / 欄位（Column / field） | 每一列都有的一項資訊，例如電子郵件或價格。 |
| 主鍵（Primary key） | 每一列的唯一 ID，通常是數字或隨機字串。 |
| 外鍵（Foreign key） | 指向另一張資料表某一列的欄位，例如預約中的 customer_id。 |
| 結構描述（Schema） | 整體設計：有哪些資料表、各自的欄位，以及彼此如何連結。 |
| 查詢（Query） | 讀取或修改資料的請求，例如「明天所有的預約」。 |
| SQL | 結構化查詢語言（Structured Query Language），查詢關聯式資料庫的標準語言。 |
| 遷移（Migration） | 可以儲存並重複執行的結構描述變更，例如新增一個欄位。 |
| 索引（Index） | 讓某個欄位的搜尋更快的查找結構，就像書的索引。 |
| CRUD | 建立（Create）、讀取（Read）、更新（Update）、刪除（Delete），是應用程式處理資料的四種基本操作。 |
| 備份（Backup） | 資料的副本，發生問題時可以用來還原。 |
資料庫的類型
| 類型 | 儲存資料的方式 | 範例 | 適合用於 |
|---|---|---|---|
| 關聯式（SQL） | 具有固定欄位、彼此連結的資料表 | Postgres、MySQL、SQLite | 大多數商業應用程式：預約、商店、CRM、SaaS |
| 文件式（NoSQL） | 有彈性的類 JSON 文件 | MongoDB、Firestore | 每筆紀錄的結構差異很大的資料 |
| 鍵值（Key-value） | 以鍵儲存的值 | Redis | 快取、工作階段等短期資料 |
對於創業者或小型企業首先要建置的幾乎所有東西，關聯式資料庫都是安全的預設選擇。
資料庫在應用程式中的位置
訪客不會直接與資料庫溝通。他們瀏覽器中的頁面（前端）會向你的伺服器（後端）要資料，通常透過 API。伺服器會檢查是誰在請求，以及是否有權限，然後查詢資料庫，只把該使用者應該看到的內容回傳。
這個中間步驟很重要。如果瀏覽器可以直接以完整權限查詢資料庫，任何人只要打開開發者工具，就能讀取所有資料。
常見錯誤與誤解
- 把資料只存在瀏覽器裡。 瀏覽器儲存空間（例如 localStorage）只存在於一台裝置、一個瀏覽器中。記住篩選條件還可以，但訂單不行。
- 把所有東西塞進同一張資料表。 一張「預約」表，每一列都複製了客戶的姓名、電話與服務價格，很快就會不同步。
- 以純文字儲存密碼。 密碼應該經過雜湊處理，絕不能以可讀的形式儲存。請參閱什麼是驗證。
- 資料沒有規則。 如果沒有必填欄位與唯一性規則，你最後會得到沒有日期的預約與重複的客戶。
- 忘了考慮刪除。 要先決定刪除客戶時，是否也刪除他的預約、保留預約，還是直接禁止刪除。
- 用正式資料做實驗。 先在安全的地方測試有風險的變更，並保留備份。
- 永遠把試算表當成資料庫。 試算表很適合剛開始時使用，但面對許多同時使用者與權限控管時會力不從心。請參閱如何把試算表變成應用程式。
該向你的 AI 建置工具要求什麼
- 「把這些存進資料庫，不要存在瀏覽器中。請告訴我你會建立哪些資料表。」
- 「用簡單的表格向我展示結構描述：每張資料表、它的欄位，以及它們如何連結。」
- 「一位客戶可以有多筆預約；每筆預約只對應一項服務和一位員工。」
- 「客戶的電子郵件必填且唯一。」
- 「阻止同一位員工的兩筆預約時間重疊。」
- 「只有已登入的擁有者能讀取所有預約；客戶只能看到自己的預約。請在伺服器端強制執行這項規則。」
- 「刪除服務時，不要刪除過去的預約，請改為將該服務標示為停用。」
Mythex 中的資料庫
當你的應用程式需要儲存資料時，Mythex 會在專案中加入一個專用的 Postgres 資料庫。你可以在聊天中提出需求（「把候補名單的報名資料存進資料庫」），也可以使用 /database 指令。連線資訊會自動傳給你的應用程式，代理會建立資料表。資料庫在五分鐘閒置後會進入休眠，並在下一次請求時喚醒；已發布的用量，則依資料庫醒著的時間計費，並從與建置相同的點數餘額中扣除。免費方案與 Pro 方案都可以使用。細節請參閱資料庫文件，而應用程式範本也提供了以資料為基礎的起點。
常見問題
用簡單的話說，什麼是資料庫？
資料庫是一個有組織的資訊儲存區，應用程式可以寫入與讀取，例如使用者、訂單或預約。與只存在瀏覽器分頁中的資料不同，資料庫中的資料在重新整理、重新啟動後，或從另一台裝置打開應用程式時，依然都在。
試算表是資料庫嗎？
試算表可以存放同樣類型的資料，但它不是為應用程式設計的。真正的資料庫會強制規範每一欄應該放什麼，可靠地把資料表彼此連結，能同時處理許多人寫入，並控制誰可以讀取什麼。
SQL 與 NoSQL 資料庫有什麼不同？
SQL（關聯式）資料庫，例如 Postgres 與 MySQL，把資料存在具有固定欄位與彼此關聯的資料表中。NoSQL 資料庫，例如 MongoDB，則儲存較有彈性的文件。大多數商業應用程式（預約、CRM、商店）都很適合關聯式模型。
我的應用程式需要資料庫嗎？
如果它需要記住使用者輸入的任何內容，例如註冊、訂單、訊息或設定，並且之後要顯示出來或讓其他人看到，那就需要。純資訊型、沒有會儲存資料的表單的網站，通常不需要。