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

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

這聽起來很抽象。但拆開來看，它做的就是 四件事：把資料的形狀守住（結構化）、找得快（高效查詢）、多人同時動不打架（並發控制）、斷電後還活著（持久化）。這四件事缺一個，都不能叫資料庫。

下面分三步把這件事吃進去： 先看「跨裝置共享」實際長什麼樣 → 再定位資料庫在整個系統裡的「居住階層」 → 最後一關一關拆它做的四件事。

你用 AI 做註冊頁時，前端會擋 email 沒 @、年齡填中文、密碼太短 — 但前端可以被繞過，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) -- 不能負
);

怎麼用：跟 AI 描述五種規則就夠 — 必填、型別、格式、範圍、外鍵 / 唯一。AI 自動翻成 CREATE TABLE 的約束。 NoSQL 沒這層 — 什麼都收，等你讀資料才發現一半對不上。

想像一本厚厚的字典，但沒有目錄 — 要找「資料庫」這個詞，只能從第一頁翻到最後一頁。100 頁還好，100 萬頁就崩潰。 這叫 full table scan（全表掃描），資料量愈大花的時間愈久 — 工程師會說「複雜度是 O(n)」，意思就是「跟資料量 n 成正比」。

Index（索引） 就是幫某個欄位多做一份「目錄」。最常見的是 B-tree（像一棵排好順序的樹），查詢時間變成 O(log n) — 100 萬筆也只要約 20 步就找到。 還有更快的 hash 索引，等於建一張對照表，O(1) 直接拿到（不管多大筆，固定時間）。

但 index 不是免費的：每加一個 index，寫入會變慢（要同步更新目錄）、硬碟要多吃一份空間。所以哪些欄位該下、哪些不該下，是真實的工程取捨。 下面是真的 JavaScript benchmark — 同一筆 id 查 100 萬筆資料，三種方法的時間差會直接打在你眼前。

想像庫存還剩 10 件。用戶 A 跟 用戶 B 幾乎同時按下「購買」：程式先「讀」出庫存 = 10、計算「10 - 1 = 9」、再「寫回」9。 如果 A 跟 B 同時跑這三步、互不知道對方，兩人都會讀到 10、都寫回 9 — 結果應該賣兩件、庫存應該變 8，卻變成 9。少賣了一件。這就是 race condition：誰先誰後沒人管，結果取決於 OS 排程的運氣。

資料庫提供兩種解法：Transaction（交易） 用 BEGIN / COMMIT 包成「不可被打斷」的單位，資料庫鎖住那一列，A 處理完才換 B。Atomic operation（原子操作） 更直接 — 根本不抓資料，直接告訴 DB UPDATE stock = stock - 1，DB 內部保證這個運算不可分割。

你以為「資料寫進去了」就安全？其實沒這麼簡單。資料從程式出發到「真的躺在硬碟上」，中間還會在作業系統的「暫存區」停留一下 — 為了效能，OS 通常會延後寫入。 這個空窗期斷電 → 資料消失。

所以資料庫多了兩道保險：fsync 命令 OS「現在馬上把資料寫到硬碟，不准延後」；WAL（Write-Ahead Log） 先寫一份「我要做什麼」的日誌、強制落地，再去動真正的資料表 — crash 後可以照日誌重做一次。

但單機再可靠也擋不住整台機器掛掉。所以還有 Replication（複製） — 同一份資料同步到第二台、甚至放到別的機房。主庫掛了從庫頂上，這就是「高可用」的基本招式。

AI 時代介面是廉價的 — Instagram、Netflix、Spotify 的 UI，AI 看一眼就能仿。那為什麼大家不換家？因為真正貴的東西在資料庫裡：追蹤的 800 個朋友、看過哪些影片到第幾分鐘、失戀那週狂播哪首歌 — 新平台抄不走也補不回來。

對 vibe coder 的啟示：跟 AI 設計 schema 時主動加一句「哪些欄位之後會變值錢？用戶行為、互動記錄、偏好歷史，第一天就要存」— 護城河是滴水穿石的，不能事後補。

AI 沒給 context 時預設給你 Firebase / Supabase — 因為它不知道你的需求是哪一型。 但其實 90% 的個人 App 都長得像下面 3 種之一： 自己用的工具型 App、有金流的交易型 App、讀重型的社群 App。

找到最像你的場景，直接複製它的 prompt 去問 AI — 比起硬填一張問卷，這樣的 context 更具體，AI 也更知道你在哪個權衡點上。