說說框架的資料庫遷移功能

laravel中有個資料庫遷移功能，migration。基本用法就是在database/migrations/的資料夾下面建立遷移資料庫的類，在這個類中實現兩個方法：

up() 和 down()

up表示執行這個資料庫遷移你要做些什麼，down表示你回滾這次資料庫遷移你要做些什麼。

這樣你就可以使用 php artisan migrate 就可以進行資料庫遷移， php artisan migrate:rollback 就可以進行遷移回滾。

我一直在想，這個東西到底是雞肋還是銀彈呢？

這個功能發明出來的大致功能是為了讓各個環境更好同步資料庫。比如一個人A開發一個評論模組，需要做兩個動作，那麼A就建立一個migrate類，在裡面用創造一個評論表，然後可能在文章表那裡增加一個評論數的欄位。當A把程式碼同步到主幹分支的時候，B這個時候獲取到了程式碼，那麼就很簡單實用php artisan migrate就能使用程式碼增加評論表和修改文章表欄位。甚至於，在測試環境修改後到線上環境執行就可以同步表修改了。

但是總是覺得這裡有幾個問題：

首先是這個功能在專案上線之後很難使用。他至多隻能同步各個人的開發環境，而不能同步線上環境。因為你想啊，我們平時線上修改是先改表還是先上程式碼？一般是先改表的。才上程式碼的。那麼這樣，我們就不大會選擇線上上直接執行php artisan migrate的行為。一旦不會選擇在上線後使用這個功能，就代表這個功能的使用場景大打折扣了。

其次是，這個行為安全性得不到保障。migrate的行為說到底是使用程式碼來控制資料庫，和php裡面執行alter table命令一樣。一般來說，改錶行為是一個非常危險的行為，越危險行為做的安全路子就是讓鏈條變短。我們使用了php來執行一個改表命令，萬一，資料量大的時候，改表非常慢，鎖表，甚至於觸發到php的命令耗時上限等行為？具體這個改錶行為會有何後續行為？你如何回滾？這個時候，你就會懵了…用程式碼來管理資料庫，我的結論就是一個，不純正！！什麼東西都有其專業的領域，用最專業的工具來做最專業的事情。

還有就是，migrate的rollback簡直就是一個定時炸彈。我們一般往migrate的down裡面寫的是droptable的操作。一旦，萬一，這種命令線上上被執行了。那麼，就相當於是一個rm -rf的命令啊。把所有資料都給刪除了。所以，安全起見，還是離這個rollback操作遠一點好。

下面來說說開發階段，在開發階段我們會頻繁修改資料庫，那麼這個時候，如果你想要維護一個很完善的migrate列表，你會很痛苦地發現你的migrate下的檔案何其多啊。但最後，我們真的關注資料庫是如何變化的麼？其實，不關注。這些migrate的命令到最後確實沒有多大用處。筆者的實踐經歷，到了一個專案準備上線的時候，我都恨不得把這些migrate的檔案匯聚成一個migrate檔案呢。。所以呢，在開發階段，維護一個migrate列表，我感覺倒不如維護一個db.sql，外加laravel的初始化資料工具。每次有資料表改動，讓大家source表，再初始化資料更好。

所以，綜上所訴，結論是：框架的資料庫遷移是個雞肋。

本文轉自軒脈刃部落格園部落格，原文連結：http://www.cnblogs.com/yjf512/p/6513328.html，如需轉載請自行聯絡原作者