哈囉！大家好～
經過前幾天修修改改程式之後，To-do List 已經成功與資料庫連線，並且可以透過 API 來修改資料庫裡的資料！如果有測試修改的話，就會在資料庫裡面看見資料已經成功修改了。如下圖：

然而，在真實情境下是這樣的～

能夠透過 API 修改資料庫裡面的資料很正常！而且這是必須要完成的功能。但實際上是…

「 啊！這邊需要再新增一個欄位耶 」、「 恩…這個欄位好像跟這個欄位統計的資料差不多，可以留其中一個就好 」、又或是「 哇！這個表的欄位名稱，都需要改一下 」….類似的需求。

畢竟專案開發會一直跟進、修正，所以這些事情也就有機會發生了。
所以，在今天的分享中，就要介紹資料庫的版本管理：Migration！

AutoMigrate 不夠用嗎？ 為什麼需要 Migration？

在 main 檔案中，已經有了一個 AutoMigrate 了，不是已經有自動更新的功能了嗎？
→ 是，但是它的功能是「 自動建表 」。所有的 DB 修改都是依靠我們手動，然後再重啟 server，拿到更新後的表。

database.DB.AutoMigrate(&model.Task{}) 

而 Migration 則是可以讓資料庫 schema 隨著需求更新，而不需要手動刪除或重建。而且這個過程都會有記錄！

紀錄，是專案開發中很重要的資料，也是專案上線之後很重要的資料！所以在這之間的過程中，只要 Schema 有更動，都需要被記錄下來～

這邊先介紹一下什麼是 Schema？ → 就是資料表的結構！
它會告訴資料庫：

1. 有哪些欄位（columns）
2. 每個欄位的型態（int、text、boolean）
3. 哪一些欄位不能為空（null）
4. 哪個欄位是 Primary Key
5. 有沒有預設值
6. 有沒有時間戳記（created_at, updated_at 等）

以 To-do List 為例，tasks 就是資料表。而以下就是 tasks 資料表的 schema：

CREATE TABLE tasks (
  id INTEGER PRIMARY KEY AUTOINCREMENT,  // Primary Key，自動編號
  item TEXT NOT NULL,                    // 項目名稱，不能為空
  status BOOLEAN DEFAULT 0,              // 狀態，預設 false
  created_at DATETIME,                   // 建立時間
  updated_at DATETIME,                   // 更新時間
  deleted_at DATETIME                    // 刪除時間
);

所以，當今天我們把 status 的型態從 BOOLEAN 改成 TEXT 、更改欄位名稱（ex：item → title）、新增一個欄位的時候，就表示「 資料表 schema 改變 」了。而這些就需要透過 Migration 來紀錄並更新資料庫的變化。

Migration 就像是 Git 的程式版本控制一樣，可以往前更新版本或往後復原版本。
所以 Migration 的好處有：

1. 資料庫結構一致且同步（利於團隊合作）。
2. 可追蹤修改紀錄。
3. 版本控制。
4. 資料庫自動化。

看完介紹之後，是不是比較了解 Migration 在做什麼了，明天我們就會實作把 Migration 加入到 To-do List 專案中～