Schema

資料庫中資料表、欄位、型別與關係的設計。

先用一句話理解

資料庫中資料表、欄位、型別與關係的設計。

打個比方

像倉庫貨架規格，規定每格放什麼資料。

什麼時候會遇到

建立資料庫、設計訂單、會員、權限等資料時。

再往深一點看

Schema 定義了資料庫裡「有哪些表格、每張表有哪些欄位、每個欄位是什麼型別（文字、數字、日期）、哪些欄位不能是空值、哪些欄位要連到另一張表的 id」。設計 schema 就是在決定資料的骨架：訂單表要不要存商品名稱的快照、還是只存商品 id？使用者的地址是獨立一張表還是存在訂單裡？這些決定一旦上線、資料進來，要修改就必須透過 migration，代價很高。Schema 不只存在於關聯式資料庫，ORM 工具（如 Prisma）也用 schema 檔案來描述資料結構，讓你用程式語言定義，工具再幫你生出對應的 SQL。

舉個例子

你在 Supabase 設計一個訂位系統：users 表有 id、email、name；reservations 表有 id、user_id（對應 users.id）、date、party_size、status。schema 設計好之後，任何人預訂都只存一份使用者資料，訂位記錄透過 user_id 關聯，不重複儲存姓名與 Email。

常見誤解

- 一開始沒有設計表格之間的關係，後面要查「某個使用者的所有訂單」才發現要掃全表。
- 對所有欄位都允許 NULL，沒有加必填限制，結果資料庫裡混入大量缺失欄位的髒資料。
- 欄位型別選錯（例如把金額存成浮點數），後來出現小數點計算誤差，財務資料對不上帳。