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

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

所以正確的做法應該是，Migration只負責Schema相關的事宜，而不該過問數(shù)據(jù)的細節(jié)，具體的數(shù)據(jù)細節(jié)，全部交由rake任務來做，并且這些rake任務也不是一成不變的，隨著時間的推移它們也會廢棄掉，但因為它們與系統(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

任務會遍歷所有用戶，想想如果數(shù)據(jù)集很大會怎樣
通過ActiveRecord更新數(shù)據(jù)，會觸發(fā)模型中的驗證和創(chuàng)建回調(diào)方法
通過if條件語句來判斷是否需要更新數(shù)據(jù)
不能直觀的看出這個任務是干什么的，沒有一個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我們可以清楚的知道任務的意圖，并且它也會顯示在rake -T中
通過scope解決了if語句的問題
引入了計數(shù)器，以及執(zhí)行狀態(tài)顯示，能讓我們了解到程序運行時的情況
把數(shù)據(jù)的更改放到了事務中執(zhí)行，可以語法因為數(shù)據(jù)異常，奔潰導致的不一致問題
最后要補充說明的一點是，有時候，可能直接用SQL語句更簡單有效，特別是在數(shù)據(jù)集比較大的情況下，一條SQL能幫你省去不少無謂的循環(huán)！另外，記得上開發(fā)環(huán)境之前，最好預先檢測一下Rake任務的有效性。