rake db:drop && rake db:setup vs rake db:reset
rails guides 上说两者是等价的
但其实，如果table无法被drop的话，会抛异常，但还是会直接执行接下来的rake db:setup. 而且，会有一大堆的输出，很可能会忽视这个异常。。。也就不会知道，其实table送来就没有被drop掉。。。
rake db:setup != rake db:create && rake db:migrate
rake db:setup runs db:schema:load, db:seed
db:schema:load loads the schema into the current env's database
rake db:migrate runs migrations for the current env that have not run yet
rake db:migrate
db:migrate runs migrations for the current env that have not run yet
db:migrate:up runs one specific migration，简单来说，就是你可以跑某个单独migration.
db:migrate:down rolls back one specific migration
db:migrate:status shows current migration status
change and up, down
如果是创建一个表，migration文件内的代码是可以推断出如何创建和滚回，就可以把migration命令放在change方法下。比如create_table，那么，其反向操作一定就是drop_table，所以把它放在change里面就好了。
而有些情况却无法做出这样的推断，比如 remove_column，这种情况就需要分别写up和down方法。
是否一定要可以down?
有人说生产环境，其实很少有滚回的情形，所以down不是必须的。
但开发的时候，如果有down，如果发现migration内有错误，滚回去，再重新migrate一次，还是很有用的。
个人认为，就是migration没办法回滚也不算是一种错误，具体看团队要求。
schema version
每个migration文件的前半部分是时间，比如20150422065741_create_foos.rb
最后一个跑过的migration文件的时间，会被设置成schema的version。在数据库内，会有单独的表来来存储version。
