浅谈Ruby on Rails下的rake与数据库数据迁移操作
不知道你有没有把数据迁移写入Migration文件的经历，相信无论是老鸟还是新手都这样干过吧。事实上，这样做并不是行不通，只不过这样的实践慢慢会给你引入一些不必要的麻烦。
一般认为db/migrate文件夹里的内容是关于你数据库Schema的演变过程，每个新的开发或线上环境都要通过这些Migration来构建可用的数据库。但如果这里装入了，负责细节的业务代码，比如一些历史遗留数据的迁移代码之类的，当一段时间后，数据库的结构变化了，但Migration没有跟着变化，渐渐的曾经的辅助代码，就成了垃圾代码，不仅不能帮忙构建环境，还会让rakedb:migrate的执行过程异常中断，无形中增加了新环境的构建成本。
所以正确的做法应该是，Migration只负责Schema相关的事宜，而不该过问数据的细节，具体的数据细节，全部交由rake任务来做，并且这些rake任务也不是一成不变的，随着时间的推移它们也会废弃掉，但因为它们与系统的其它部分不想管，所以直接删掉即可。不过使用Rake做数据迁移也是有讲究的，具体如下:
BadRakeTask
#lib/tasks/temporary/users.rake namespace:usersdo task:set_newsletter=>:environmentdo User.all.eachdo|user| ifuser.confirmed? user.receive_newsletter=true user.save end end end end
任务会遍历所有用户，想想如果数据集很大会怎样
通过ActiveRecord更新数据，会触发模型中的验证和创建回调方法
通过if条件语句来判断是否需要更新数据
不能直观的看出这个任务是干什么的，没有一个desc，所以也无法通过rake-T找到它
GoodRakeTask
#lib/tasks/temporary/users.rake
namespace:usersdo
desc"Updateconfirmeduserstoreceivenewsletter"
taskset_newsletter::environmentdo
users=User.confirmed
puts"Goingtoupdate#{users.count}users"
ActiveRecord::Base.transactiondo
users.eachdo|user|
user.mark_newsletter_received!
print"."
end
end
puts"Alldonenow!"
end
end
通过desc我们可以清楚的知道任务的意图，并且它也会显示在rake-T中
通过scope解决了if语句的问题
引入了计数器，以及执行状态显示，能让我们了解到程序运行时的情况
把数据的更改放到了事务中执行，可以语法因为数据异常，奔溃导致的不一致问题
最后要补充说明的一点是，有时候，可能直接用SQL语句更简单有效，特别是在数据集比较大的情况下，一条SQL能帮你省去不少无谓的循环！另外，记得上开发环境之前，最好预先检测一下Rake任务的有效性。