上一個 Part 你學會了「選哪個資料庫陣營」。選好之後，下一步是把現實世界翻譯成一張張表格。 Schema 是你 App 的藍圖，而每個欄位的「資料型態」是第一道守門員。這個 unit 帶你親手踩過四個最常見的型態陷阱： Float 精度、字串排序、Boolean 字串、時區，看懂 AI 給的 schema 哪裡會出包。
資料庫不認識「一個 Spotify 使用者」。它只認識欄位（column）跟一筆筆資料（row）。
點任一個屬性，看它對應到右邊表格的哪一欄。
| id INTEGER | display_name TEXT | email TEXT | is_premium BOOLEAN | country TEXT |
|---|---|---|---|---|
| 1 | Mia | mia@x.com | true | TW |
| 2 | Mei | mei@x.com | false | JP |
這是 App 裡一位使用者的個人頁。資料庫不認識「畫面」，
它只把這個人記成一張表裡的一橫列。
users 表，需要 email、是否付費、國家、註冊時間這幾個欄位，幫我各配一個適合的型態。」型態是接下來整個 unit 的重點。型態不只是分類，它是第一道守門員。選對了，髒資料寫不進來；選錯了，bug 等著你。
這是六種最常見的型態速查表。下面四段把最容易選錯的四個坑，各帶你親手踩一遍。
TEXT 通吃一切，因為「字串什麼都裝得下、最不會報錯」。但裝得下不代表正確，型態鬆掉了守門功能也跟著消失。DECIMAL 不要 FLOAT，時間用 TIMESTAMPTZ，開關用 BOOLEAN，手機號用 TEXT。」電腦用二進位存小數，0.1 沒辦法被精確表示。一筆筆加起來，誤差會浮出來。
price FLOAT 或 REAL。Demo 金額小看不出來，等到對帳、退款、累計營收才爆。DECIMAL(10,2)，或在程式裡一律以整數『分』儲存，絕對不要用 FLOAT。」文字是「一個字一個字比」，所以「10」會排在「9」前面，因為第一個字 1 比 9 小。
ORDER BY 就露餡。INTEGER / DECIMAL）或時間型態，不要用字串。」在程式裡，只要不是空字串，任何字串都算 true。所以字串「false」跟「0」其實都是「真」。
if (value)，字串 "false" 會被當成 true。BOOLEAN 型態；如果來源是字串，幫我明確轉換（例如 value === "true"），不要直接拿字串判斷。」直播在台北時間晚上 8 點開始。如果只存「20:00」這串字，東京、紐約的觀眾會以為是他們的當地 8 點。
DATETIME 或乾脆字串。本地測試（同一個時區）永遠看不出問題，上線遇到海外使用者才炸。TIMESTAMPTZ（帶時區），一律以 UTC 儲存，只在顯示給使用者時才轉成他的當地時區。」光有型態還不夠。NOT NULL、CHECK、DEFAULT 這些約束，讓不合理的資料根本寫不進來。
| id | age | role | |
|---|---|---|---|
| 1 | mia@x.com | 28 | admin |
age >= 0 擋掉負年齡，price > 0 擋掉負價格。'user'，省得每次都要寫。NOT NULL、有範圍的加 CHECK、有預設的加 DEFAULT。」唯一性（UNIQUE）跟關聯約束，下一個 unit 會講。答錯不會鎖死，黃色提示會告訴你為什麼，換一個再試。
💰商品價格（會用來加總、結帳）
✅使用者 email 驗證了沒
🕐貼文發布時間（使用者遍布全球）
📱手機號碼（可能有開頭 0、+886）
👍文章的按讚數
到這裡你已經會設計「一張表」了。但真實的 App 有很多表，它們要怎麼認得彼此？下一課（PK & FK）告訴你。
把型態直覺收進口袋，跟 AI 一起建表時隨時拿出來用。
型態是 schema 的第一根支柱，管「每一格裝什麼」。AI 常為了「能跑、寫得快」用 TEXT 通吃、不加約束，你現在看得懂也問得出對的問題。
但真實的 App 有很多張表，它們要怎麼認得彼此？下一課（PK & FK）講 schema 的第二根支柱：表跟表怎麼連。