什麼是資料庫？
為什麼 AI 時代更需要懂它？

資料庫不是「比較厲害的檔案」、也不是「線上版 Excel」。它存在的理由很單純：讓資料活過程式的生命週期、讓不同裝置的不同人讀到同一份。

→ 知道資料庫是什麼之後，先別急著學它怎麼運作。下一段先講一件更高層的事：為什麼「累積的資料」是 AI 時代最拿不走的資產。

AI 時代 介面是廉價的，AI 看一眼就能仿。真正貴的是被存下來的東西：你追蹤的 800 個朋友、看到第幾分鐘、失戀那週狂播哪首歌，新平台抄不走、也補不回來。下面點不同品牌，看它的護城河是什麼。

→ 知道資料值錢之後，接下來先綜觀一遍：一個真正的資料庫，到底默默幫你顧了哪四件事。

→ 四件事先有個輪廓了。接下來一件一件拆開玩，從第一件「結構化」開始。

前端能擋的，AI agent、webhook、後台腳本 都能繞過、直接寫進資料庫。Schema 是把同一套規則寫進資料庫本身，每條寫入路徑都被它當下擋下。

做一個 users 表：
- 每個人一定要有名字
- 年齡要是數字
- email 要長得像 email
- 價格不能是負的

CREATE TABLE users (
  name  TEXT    NOT NULL,          -- 一定要有名字
  age   INTEGER,                   -- 數字
  email TEXT    CHECK (email~'@'), -- email 格式
  price NUMERIC CHECK (price >= 0) -- 不能負
);

→ Schema 守住資料的形狀，但 100 萬筆裡找一筆還是慢，這是下一段要解決的問題。

沒有目錄的字典要一頁頁翻（full table scan），資料愈多愈慢。Index（索引） 就是幫某個欄位多做一份「目錄」，把查詢從「跟資料量成正比」變成「幾步就到」。

但 index 不是免費的：每加一個，寫入變慢、多吃硬碟空間，哪些欄位該下是真實的工程取捨。下面是真的 benchmark，100 萬筆的時間差直接打在你眼前。

→ 找得快了，但同一筆資料兩個人同時要改怎麼辦？這就是下一段的並發控制。

庫存剩 10，A 和 B 幾乎同時按購買：各自「讀到 10 → 算 9 → 寫回 9」，該賣兩件卻只扣一件。這就是 race condition，誰先誰後沒人管、靠 OS 排程的運氣。切換下面三種寫法看差別。

→ 結構、查詢、並發都做了，但機器一斷電全沒了，這就是下一段的持久化。

「寫進去了」其實有等級之分：資料從程式到「真的躺在硬碟上」，中間會在 OS 暫存區停留，這個空窗期斷電就消失。資料庫用三道保險頂住。

→ 結構、查詢、並發、持久，四件事都各別玩過了。接下來換你實戰複習：看 AI 給的方案，到底漏了哪一件。

→ 最後補一個本能：其實「並不是所有資料都該丟進資料庫」，下一段教你怎麼分。

每份資料都歸到三個位置之一。分錯桶會出事（訂單放 useState 重整就棄單、搜尋記憶放資料庫每筆都打 server），而 AI 沒 context 時「預設往最簡單那層猜」。下面拖卡片，把每份資料分到對的桶。

→ 分完桶你才知道哪些丟資料庫、哪些留前端。這個 Unit 差不多了，最後收個尾。