資料庫是 App 最早、也最難改的決定。先看選錯多痛，再把 SQL 和 NoSQL 一次搞懂，學會跟 AI 一起替你的 App 選對。
資料庫是 App 最早、也最難改的決定。選的當下都沒事，但流量長大後，當初的選擇會一個一個變成帳單與災難。拖時間軸看看。
→ 既然選對這麼重要，下一步先認識：市面上到底有哪些主流的資料庫，它們差在哪。
先認得幾個主流資料庫，再看最大的分水嶺：SQL 還是 NoSQL。
最大的分水嶺只有一個：SQL 還是 NoSQL，背後是兩套設計哲學。
→ 先把 SQL 一次講完（關聯式、JOIN、ACID），再把 NoSQL 一次講完（Document Model、CAP），最後比較取捨。
→ 先進入 SQL 這一派，下一段看關聯式資料庫到底怎麼工作。
上一段給了兩派高層比較，這段進入 SQL 這一派背後的設計：關聯式模型（1970 年 Codd 提出）。
SQL 的底層哲學「關聯式模型」：把資料切成多張 表，每張只描述一種東西，表跟表之間用 id 互相指。
users.id。不能重複、不能空。orders.user_id 指向 users.id；DB 會檢查被指的對象一定要存在。| id | name | |
|---|---|---|
| u1 | 小明 | a@x.com |
| u2 | 小華 | b@x.com |
| id | user_id | product_id | qty |
|---|---|---|---|
| o1 | u1 | p1 | 2 |
| o2 | u2 | p1 | 1 |
| o3 | u1 | p2 | 3 |
| id | name | price |
|---|---|---|
| p1 | 拿鐵 | 120 |
| p2 | 可頌 | 80 |
按下面兩顆按鈕體感差別：同樣「把小明改名」，扁平表要動 3 筆，正規化只動 1 筆。
| order | author | product | |
|---|---|---|---|
| o1 | 小明 | ming@x.com | 拿鐵 |
| o2 | 小華 | hua@x.com | 拿鐵 |
| o3 | 小明 | ming@x.com | 可頌 |
| o4 | 小明 | ming@x.com | 拿鐵 |
| u1 | 小明 | ming@x.com |
| u2 | 小華 | hua@x.com |
→ 切表之後，要用時得想辦法把表拼回來，這就是下一段的 JOIN。
前面把資料切成多張表，這段把表拼回來。切換 4 種 JOIN 看「誰留下、誰被丟掉」。
把切開的表 拼回來 叫 JOIN。四種寫法差別只在一件事：對不上的列要不要留？下面故意放兩個邊界 case（沒下單的小美、用戶已刪的舊訂單），切換 4 種 JOIN 看誰留誰丟。
| user | item | 這列的命運 |
|---|---|---|
| 小明 | 拿鐵 | ✓ 配對成功，留下 |
| 小華 | 可頌 | ✓ 配對成功，留下 |
| 小明 | 美式 | ✓ 配對成功，留下 |
| 小美 | NULL | ✗ 丟掉（users 有，沒下過訂單） |
| NULL | 舊訂單（用戶已刪） | ✗ 丟掉（orders 有，用戶被刪了） |
SELECT users.name, orders.item FROM users INNER JOIN orders ON users.id = orders.user_id
→ JOIN 把資料拼回來，但 SQL 真正的看家本領是「保證不出錯」，這就是下一段的 ACID。
JOIN 讓你查得到資料，但 SQL 最厲害的其實是「保證不出錯」，這就是 ACID。按按鈕看四種「壞掉的轉帳」，每種對應 ACID 少了一個字母。
轉帳要做兩件事（A -$100、B +$100），中間不管出什麼狀況錢都不能憑空消失。這四個保證合起來叫 ACID，打包在一起叫 Transaction。按下面五顆按鈕，看少了哪個字母會出什麼事。
→ 關聯式、JOIN、ACID，SQL 這一派到這裡講完了。接下來換另一派 NoSQL，先看它的核心 Document Model。
跟 SQL 對立的哲學：不切表，整坨包成 document。同樣是作者改名，NoSQL 要動 12 筆、SQL 只動 1 筆。
NoSQL 文件式（Firestore、MongoDB）跟 SQL 相反：不切表，把「會一起讀」的資料整坨包成一份 JSON document。
資料一旦 分散到多台，就撞上分散式系統的鐵則 CAP 定理：下面三個 最多同時有兩個。P 是現實（網路本來就會斷），所以真正的選擇是 CP 還是 AP。拖三角看取捨。
→ SQL 跟 NoSQL 兩派都看完了，接下來把它們放一起比較：改結構時，各自要付出什麼代價。
SQL 嚴格 schema 跟 NoSQL 彈性 schema 改起來代價差很多。產品快速迭代時加欄位是日常，方便有代價，只是「方便」被推到哪去而已。
產品長大常要「加新欄位」。「方便」不會消失，只是被推到不同地方。下面兩顆按鈕體感差別。
ALTER TABLE 宣告、回填舊資料。大表可能 鎖表幾分鐘到幾小時。?? "default"。ALTER TABLE 不提鎖表時間。小表沒事，但 100 萬筆以上的大表 ALTER 可能鎖數分鐘到數小時，整個 App 寫不進去。→ 概念都齊了，接下來先看 AI 時代最常見的後端長什麼樣。
一個 vibe coder 的開發直播：每加一個需求，自然逼出一張表。點按鈕，跟著長一遍。
→ 概念跟範本都看過了，換你做選擇練習：下一段用 5 個場景測測你的直覺。
前面把概念都講完了，這段把它們套到 5 個具體場景。從 SQL / NoSQL / Key-Value 三個選項挑一個，立即知道對錯 + 為什麼。
選資料庫先看 場景特性，不是先看名字。下面 5 題每題給一個場景、3 個選項，先憑直覺答，答錯沒關係。
知道四個陣營後，下一層是「每個陣營有哪些代表產品」。不用背特性，看到名字能反應「它大概解什麼問題」就夠了。
你要做一個轉帳系統，需要 ACID 保證、強一致性。AI 應該推薦哪個？
你要做即時協作聊天 App，訊息要「資料變了 client 自動收到」。AI 預設會推哪個？
你要做一個 AI 客服 + RAG 語意搜尋，剛起步、規模小。AI 應該推哪個？
你要做 API 限流（每個 user 每分鐘最多 100 次），計數要超快。AI 推哪個？
你是 vibe coder，想要一站式後端（資料庫 + 登入 + 即時同步 + Storage），不想自己架 server，資料結構也會邊做邊改。AI 推哪個？
→ 走完整個單元，你已經有跟 AI 對話的全套後端直覺，最後一段把它收口。
SQL vs NoSQL 不是「哪個比較好」，
是「在這個場景哪個比較適合」。
跟 AI 討論架構時可以直接用的 7 個直覺：
知道選哪個陣營之後，下一步是學會「畫出你的 App 的資料地圖」，怎麼跟 AI 一起把 schema 設計好，少踩遷移地獄。