Migration

用可追蹤、可重播的方式修改資料庫結構。

先用一句話理解

用可追蹤、可重播的方式修改資料庫結構。

打個比方

像倉庫改裝紀錄，每次改貨架都留下版本。

什麼時候會遇到

資料庫 schema 要隨產品版本改動時。

再往深一點看

Migration 是一個版本化的 SQL 腳本：每一次 schema 變動（新增欄位、改型別、刪表）都寫成一個 migration 檔案，按順序執行就能把任何一個空資料庫還原到當前版本。它解決的問題是：當你本機開發改了 schema，怎麼確保測試環境、正式環境、其他開發者都跟著一起更新，而不是靠口頭交代「去資料庫加一個欄位」。ORM 工具（如 Prisma）和資料庫平台（如 Supabase CLI）都有自動生成 migration 的功能，你改 schema 定義後執行一個指令就生出對應的 SQL 檔案。好的 migration 習慣讓資料庫結構的演進可以被 git 追蹤，也可以在出錯時回滾。

舉個例子

你的 App 原本沒有「分類」功能，新版要幫商品加 category 欄位：你在 Prisma schema 加上欄位、執行 prisma migrate dev，工具自動生出一個 migration 檔案、對本機資料庫執行。部署到正式環境時，CI 流程執行同一個 migration，正式資料庫自動跟著更新，不需要手動進 Supabase 後台加欄位。

常見誤解

- 直接在正式環境後台手動加欄位或改型別，沒有任何紀錄，其他人的本機環境和測試環境都沒跟到，之後 migration 順序就亂掉。
- 把帶有大量舊資料的欄位直接標為 NOT NULL 卻沒有設預設值，migration 執行時因為舊資料違反限制而失敗，正式環境資料庫短暫掛掉。
- 刪除欄位的 migration 跑太快，但程式碼部署還沒完成，舊版程式嘗試讀取已刪除的欄位而報錯。