不知道你有沒有把數(shù)據(jù)遷移寫入Migration文件的經(jīng)歷，相信無論是老鳥還是新手都這樣干過吧。事實(shí)上，這樣做并不是行不通，只不過這樣的實(shí)踐慢慢會給你引入一些不必要的麻煩。

一般認(rèn)為db/migrate文件夾里的內(nèi)容是關(guān)于你數(shù)據(jù)庫Schema的演變過程，每個新的開發(fā)或線上環(huán)境都要通過這些Migration來構(gòu)建可用的數(shù)據(jù)庫。但如果這里裝入了，負(fù)責(zé)細(xì)節(jié)的業(yè)務(wù)代碼，比如一些歷史遺留數(shù)據(jù)的遷移代碼之類的，當(dāng)一段時間后，數(shù)據(jù)庫的結(jié)構(gòu)變化了，但Migration沒有跟著變化，漸漸的曾經(jīng)的輔助代碼，就成了垃圾代碼，不僅不能幫忙構(gòu)建環(huán)境，還會讓rake db:migrate的執(zhí)行過程異常中斷，無形中增加了新環(huán)境的構(gòu)建成本。

所以正確的做法應(yīng)該是，Migration只負(fù)責(zé)Schema相關(guān)的事宜，而不該過問數(shù)據(jù)的細(xì)節(jié)，具體的數(shù)據(jù)細(xì)節(jié)，全部交由rake任務(wù)來做，并且這些rake任務(wù)也不是一成不變的，隨著時間的推移它們也會廢棄掉，但因為它們與系統(tǒng)的其它部分不想管，所以直接刪掉即可。不過使用Rake做數(shù)據(jù)遷移也是有講究的，具體如下:

Bad Rake Task

# lib/tasks/temporary/users.rake
namespace :users do
 task :set_newsletter => :environment do
  User.all.each do |user|
   if user.confirmed?
    user.receive_newsletter = true
    user.save
   end
  end
 end
end

任務(wù)會遍歷所有用戶，想想如果數(shù)據(jù)集很大會怎樣
通過ActiveRecord更新數(shù)據(jù)，會觸發(fā)模型中的驗證和創(chuàng)建回調(diào)方法
通過if條件語句來判斷是否需要更新數(shù)據(jù)
不能直觀的看出這個任務(wù)是干什么的，沒有一個desc，所以也無法通過rake -T找到它
Good Rake Task

# lib/tasks/temporary/users.rake
namespace :users do
 desc "Update confirmed users to receive newsletter"
 task set_newsletter: :environment do
  users = User.confirmed
  puts "Going to update #{users.count} users"

  ActiveRecord::Base.transaction do
   users.each do |user|
    user.mark_newsletter_received!
    print "."
   end
  end

  puts " All done now!"
 end
end

通過desc我們可以清楚的知道任務(wù)的意圖，并且它也會顯示在rake -T中
通過scope解決了if語句的問題
引入了計數(shù)器，以及執(zhí)行狀態(tài)顯示，能讓我們了解到程序運(yùn)行時的情況
把數(shù)據(jù)的更改放到了事務(wù)中執(zhí)行，可以語法因為數(shù)據(jù)異常，奔潰導(dǎo)致的不一致問題
最后要補(bǔ)充說明的一點(diǎn)是，有時候，可能直接用SQL語句更簡單有效，特別是在數(shù)據(jù)集比較大的情況下，一條SQL能幫你省去不少無謂的循環(huán)！另外，記得上開發(fā)環(huán)境之前，最好預(yù)先檢測一下Rake任務(wù)的有效性。