耙db：架构：负载与迁移
这里很简单的问题 – 如果迁移可能会变得缓慢和繁琐，应用程序变得更复杂，如果我们有更清洁的rake db:schema:load来调用，为什么迁移存在呢？
如果上面的答案是使用迁移进行版本控制（对数据库进行更改的逐步logging），那么随着应用程序变得越来越复杂， rake db:schema:load被更多地使用，他们是否继续保持它们主要function？
警告：
从这个问题的答案： rake db:schema:load 会删除生产服务器上的数据 ，所以在使用时要小心。
迁移向数据库提供向前和向后的步骤更改。 在生产环境中，部署期间必须对数据库进行增量更改：迁移提供了具有回滚失败保护function的此function。 如果在生产服务器上运行rake db：schema：load，则最终将删除所有生产数据。 这是一个危险的习惯进入。
话虽如此，我认为偶尔“崩溃”移民是一种体面的做法。 这需要删除旧的迁移，用单个迁移（与schema.rb文件非常相似）replace它们，并更新“schema_migrations”表以反映此更改。 当做这个时非常小心！ 如果你不小心，你可以很容易地删除你的生产数据。
作为一个方面说明，我坚信你永远不应该把数据创build在迁移文件。 seed.rb文件可用于此目的，或自定义耙或部署任务。 将它放到迁移文件中会将数据库模式规范与数据规范混合在一起，并在运行迁移文件时导致冲突。
刚刚偶然发现这个post，那是很久以前，没有看到我期待的答案。
rake db:schema:load是第一次你把系统投入生产的伟大。 之后，您应该正常运行迁移。
这也可以帮助您随时清理迁移，因为架构拥有将其他机器投入生产的所有信息，即使在清理迁移时也是如此。
迁移使您可以将数据添加到数据库。 但db：schema：load只加载模式。
因为迁移可以回滚，并提供额外的function。 例如，如果您需要将某些数据作为模式更改的一部分进行修改，则需要将其作为迁移来执行。
作为其他ORM的用户，我总觉得Rails没有“同步和更新”function。 即通过使用模式文件（代表完整的最新模式），遍历现有的数据库结构，并根据需要添加/删除表，列，索引。
对我来说，这将是更强大，即使可能慢一点。
我已经发布了评论，但是感觉最好把db / schema.rb文件的注释放在这里：
# Note that this schema.rb definition is the authoritative source for your # database schema. If you need to create the application database on another # system, you should be using db:schema:load, not running all the migrations # from scratch. The latter is a flawed and unsustainable approach (the more migrations # you'll amass, the slower it'll run and the greater likelihood for issues). # # It's strongly recommended that you check this file into your version control system.
其实，我的经验是，最好将迁移文件放在git中，而不是schema.rb文件中。
