把数据迁移逻辑直接写进Migration文件里，并不少见。 老鸟和新手，很多人都干过。这样写不一定跑不通，但时间一长，问题往往会慢慢出现。

为什么不建议在Migration里写数据迁移逻辑

一般认为，db/migrate 文件夹下的内容，是用来记录数据库Schema的演变过程的。每次新开发环境或线上部署，都要依靠这些Migration来构建可用的数据库结构。

但如果这里混入了具体业务相关的代码，比如历史遗留数据迁移脚本，问题就会随之而来。

过一段时间后，数据库结构变了，但这些Migration里的业务代码却没有同步更新。久而久之，原本有用的辅助代码就会变成负担。

它们不仅无法帮助构建新环境，还可能让 rake db:migrate 执行到一半时异常中断，进一步抬高新环境的搭建成本。

正确做法

Migration只负责Schema相关的事，别去碰数据细节；所有具体的数据迁移工作，全部交给单独的rake任务来处理。

而且，这些rake任务也不是永久存在的。随着系统迭代，它们可能会被废弃。但因为和系统其他部分没有耦合，直接删掉即可，没有额外负担。

反面示例：Bad Rake Task

不过，写数据迁移用的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.sa ve
   end
  end
 end
end

这个任务的问题

• 它会遍历所有用户。数据集一大，性能就会很差。

• 通过ActiveRecord逐条更新，会触发模型里的验证和回调。不但速度慢，还可能带来副作用。

• 用if条件判断是否更新，不够清晰。其实可以直接用scope处理。

• 最关键的是，没有desc描述。通过rake -T根本找不到它，后续维护的人会很难理解。

改进示例：Good Rake Task

再看看改进后的版本：

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也能正常显示。

• 使用User.confirmed这个scope替代原生的if判断，代码更简洁。

• 加入了计数信息，执行时可以打印进度，方便观察运行状态。

• 使用事务包裹，能避免中途崩溃造成数据不一致。

最后补充

有时候，直接使用原生SQL会更高效，尤其是在数据集非常大的情况下。

如果一条UPDATE语句就能解决问题，就没必要在循环里逐条处理。

另外，在上开发环境之前，最好先跑一遍测试，确认Rake任务没有问题再部署。

《夸克》非常好用的免费AI浏览器

下载APP查看