laravel中有個(gè)數(shù)據(jù)庫遷移功能，migration?；居梅ň褪窃赿atabase/migrations/的文件夾下面創(chuàng)建遷移數(shù)據(jù)庫的類，在這個(gè)類中實(shí)現(xiàn)兩個(gè)方法：
up() 和 down()
up表示運(yùn)行這個(gè)數(shù)據(jù)庫遷移你要做些什么，down表示你回滾這次數(shù)據(jù)庫遷移你要做些什么。
這樣你就可以使用 php artisan migrate 就可以進(jìn)行數(shù)據(jù)庫遷移， php artisan migrate:rollback 就可以進(jìn)行遷移回滾。
我一直在想，這個(gè)東西到底是雞肋還是銀彈呢？
這個(gè)功能發(fā)明出來的大致功能是為了讓各個(gè)環(huán)境更好同步數(shù)據(jù)庫。比如一個(gè)人A開發(fā)一個(gè)評論模塊，需要做兩個(gè)動作，那么A就創(chuàng)建一個(gè)migrate類，在里面用創(chuàng)造一個(gè)評論表，然后可能在文章表那里增加一個(gè)評論數(shù)的字段。當(dāng)A把代碼同步到主干分支的時(shí)候，B這個(gè)時(shí)候獲取到了代碼，那么就很簡單實(shí)用php artisan migrate就能使用代碼增加評論表和修改文章表字段。甚至于，在測試環(huán)境修改后到線上環(huán)境運(yùn)行就可以同步表修改了。
但是總是覺得這里有幾個(gè)問題：
首先是這個(gè)功能在項(xiàng)目上線之后很難使用。他至多只能同步各個(gè)人的開發(fā)環(huán)境，而不能同步線上環(huán)境。因?yàn)槟阆氚?，我們平時(shí)線上修改是先改表還是先上代碼？一般是先改表的。才上代碼的。那么這樣，我們就不大會選擇在線上直接運(yùn)行php artisan migrate的行為。一旦不會選擇在上線后使用這個(gè)功能，就代表這個(gè)功能的使用場景大打折扣了。
其次是，這個(gè)行為安全性得不到保障。migrate的行為說到底是使用代碼來控制數(shù)據(jù)庫，和php里面執(zhí)行alter table命令一樣。一般來說，改表行為是一個(gè)非常危險(xiǎn)的行為，越危險(xiǎn)行為做的安全路子就是讓鏈條變短。我們使用了php來執(zhí)行一個(gè)改表命令，萬一，數(shù)據(jù)量大的時(shí)候，改表非常慢，鎖表，甚至于觸發(fā)到php的命令耗時(shí)上限等行為？具體這個(gè)改表行為會有何后續(xù)行為？你如何回滾？這個(gè)時(shí)候，你就會懵了...用代碼來管理數(shù)據(jù)庫，我的結(jié)論就是一個(gè)，不純正??！什么東西都有其專業(yè)的領(lǐng)域，用最專業(yè)的工具來做最專業(yè)的事情。
還有就是，migrate的rollback簡直就是一個(gè)定時(shí)炸彈。我們一般往migrate的down里面寫的是droptable的操作。一旦，萬一，這種命令在線上被執(zhí)行了。那么，就相當(dāng)于是一個(gè)rm -rf的命令啊。把所有數(shù)據(jù)都給刪除了。所以，安全起見，還是離這個(gè)rollback操作遠(yuǎn)一點(diǎn)好。
下面來說說開發(fā)階段，在開發(fā)階段我們會頻繁修改數(shù)據(jù)庫，那么這個(gè)時(shí)候，如果你想要維護(hù)一個(gè)很完善的migrate列表，你會很痛苦地發(fā)現(xiàn)你的migrate下的文件何其多啊。但最后，我們真的關(guān)注數(shù)據(jù)庫是如何變化的么？其實(shí)，不關(guān)注。這些migrate的命令到最后確實(shí)沒有多大用處。筆者的實(shí)踐經(jīng)歷，到了一個(gè)項(xiàng)目準(zhǔn)備上線的時(shí)候，我都恨不得把這些migrate的文件匯聚成一個(gè)migrate文件呢。。所以呢，在開發(fā)階段，維護(hù)一個(gè)migrate列表，我感覺倒不如維護(hù)一個(gè)db.sql，外加laravel的初始化數(shù)據(jù)工具。每次有數(shù)據(jù)表改動，讓大家source表，再初始化數(shù)據(jù)更好。
所以，綜上所訴，結(jié)論是：框架的數(shù)據(jù)庫遷移是個(gè)雞肋。
專注Web開發(fā)50年。請加群：
網(wǎng)友評論
