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

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

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

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

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