什麼係數據庫？俾建構應用程式嘅人嘅指南
數據庫係一個有組織嘅資訊儲存庫，應用程式會寫入同讀取，例如用戶、訂單、預約、訊息。同只留喺瀏覽器入面嘅資料唔同，數據庫入面嘅資料即使重新整理或者重新啟動之後都仲會喺度，而且所有使用呢個應用程式嘅人睇到嘅都係同一批記錄。大部分數據庫會將資料組織成表格，好似試算表入面嘅工作表，但有嚴格嘅規則，確保資料保持一致。
用 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 星期五邊啲時段有空？」 — 睇佢嗰日嘅預約。
- 「染髮服務今個月賺咗幾多？」 — 將預約同服務連接，然後加埋價錢。
- 「邊啲客戶九十日冇再預約？」 — 將客戶同佢哋最近一次預約比對。
常見名詞解釋
| 名詞 | 意思 |
|---|---|
| 表格（Table） | 一類記錄嘅集合，例如客戶或預約。 |
| 資料列（Row，記錄） | 表格入面嘅一項，例如一位客戶、一個預約。 |
| 資料欄（Column，欄位） | 每一行都有嘅一部分資料，例如電郵或價錢。 |
| 主鍵（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 指令。連接資料會自動傳俾你嘅應用程式，agent 會建立表格。數據庫閒置五分鐘後會休眠，並於下一個請求時喚醒；已發佈嘅用量會按佢醒着嘅時間收費，並由建構時用嘅同一個點數結餘扣除。免費同 Pro 方案都可以用。詳情請睇數據庫文件，而應用程式範本亦提供由數據驅動嘅起步點。
常見問題
簡單嚟講，什麼係數據庫？
數據庫係一個有組織嘅資訊儲存庫，應用程式可以寫入同讀取，例如用戶、訂單或者預約。同只留喺瀏覽器分頁入面嘅數據唔同，數據庫入面嘅資料即使重新整理、重新啟動，或者用另一部裝置打開應用程式，都仲會喺度。
試算表係咪數據庫？
試算表可以儲存同類嘅數據，但佢唔係為應用程式而設計。真正嘅數據庫會強制執行每欄資料嘅規則，可靠地將表格連接起來，應付多人同時寫入，亦會控制邊個可以讀取咩。
SQL 同 NoSQL 數據庫有咩分別？
SQL（關聯式）數據庫，例如 Postgres 同 MySQL，將數據儲存喺有固定欄位同彼此關係嘅表格入面。NoSQL 數據庫，例如 MongoDB，儲存較靈活嘅文件。大部分商業應用程式，例如預約、CRM、商店，都好適合關聯式模型。
我嘅應用程式需唔需要數據庫？
如果佢需要記住人哋輸入嘅任何嘢，例如註冊、訂單、訊息、設定，並日後顯示俾佢哋或者其他人睇，就需要。純粹提供資訊、冇表格會儲存數據嘅網站，通常就唔需要。