这里有一个非常简单的问题 - 如果迁移会随着应用程序变得越来越复杂而变得缓慢和繁琐，并且如果我们可以调用更简洁的 rake db:schema:load 来代替，那么为什么还存在迁移？
如果上述问题的答案是迁移用于版本控制（对数据库的更改的逐步记录），那么随着应用程序变得更加复杂并且更多地使用rake db:schema:load，他们是否会继续维护他们的主要功能？
从这个问题的答案：rake db:schema:load 将删除生产服务器上的数据，所以使用时要小心。
【问题讨论】：
标签： ruby-on-rails ruby-on-rails-3 migration
所以 schema:load 采用当前配置的模式，派生要匹配的关联查询，并一次性运行它们。这是一种一劳永逸的情况。如您所见，迁移会逐步进行更改。在本地处理项目时加载模式可能有意义，尤其是在项目生命周期的早期。但是，如果我们在每次部署时都删除并重新创建生产数据库，每次都会丢失生产数据。那是不行的。这就是我们使用迁移对现有数据库进行所需更改的原因。
所以。您对项目的深入了解，当您对数据库进行更多更改时，您将获得更多的迁移。随着每次迁移，这些迁移越来越成为生产环境的真实来源——重要的不是架构中的内容，而是生产环境中运行的迁移。如果我们两者同步，那么差异实际上是没有意义的。但是，一旦一个与另一个过时，您就会开始出现差异。理想情况下这不会发生，但我们生活在现实世界中，并且事情会发生。如果您使用 schema:load 在本地设置数据库，您可能无法获得数据库的实际状态，因为它通过生产中的迁移历史反映。
【讨论】：
迁移提供对数据库的向前和向后步进更改。在生产环境中，必须在部署期间对数据库进行增量更改：迁移为该功能提供了回滚故障保护。如果您在生产服务器上运行rake db:schema:load，您最终将删除所有生产数据。这是一个危险的习惯。
话虽如此，我认为偶尔“崩溃”迁移是一种体面的做法。这需要删除旧迁移，用单个迁移替换它们（非常类似于您的 schema.rb 文件）并更新 schema_migrations 表以反映此更改。 这样做时要非常小心！如果您不小心，您可以轻松删除您的生产数据。
附带说明，我坚信您永远不应该将数据创建放在迁移文件中。 seed.rb 文件可用于此，或自定义 rake 或部署任务。将其放入迁移文件中会使您的数据库模式规范与数据规范混合在一起，并可能在运行迁移文件时导致冲突。
【讨论】：
db:migrate 时使用 db:schema:load反对全新安装。 @clear_migrations
rake db:schema:load 对设置您的测试数据库也非常有用。
rake db:migrate 设置数据库中的表。当您运行迁移命令时，它将在 db/migrate/ 中查找任何 ruby 文件并从最旧的开始执行它们。每个迁移文件名的开头都有一个时间戳。
与运行尚未运行的迁移的rake db:migrate 不同，rake db:schema:load 将db/schema.rb 中已生成的架构加载到数据库中。
您可以了解更多关于rake database commands here的信息。
【讨论】：
我已经发表了评论，但感觉最好把db/schema.rb文件的cmets放在这里：
# 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文件...
【讨论】：
Migrations 也允许您将数据添加到数据库。但 db:schema:load 只加载模式。
【讨论】：
偶然发现这篇文章，那是很久以前的事了，没有看到我期待的答案。
rake db:schema:load 非常适合您首次将系统投入生产。之后，您应该正常运行迁移。
这还有助于您随时清理迁移，因为即使您清理了迁移，架构也包含将其他机器投入生产的所有信息。
【讨论】：
db:schema:load 除了在整个开发周期中减少几秒钟之外还有什么好处。您是否曾经使用过一个构建时间超过 30 秒的应用程序？我目前正在开发一个应用程序，它的迁移文件中有错误，如果没有错误修复或运行db:schema:load，它永远不会向上迁移，这让我认为 schema:load 是在应用程序开发出现问题时使用的。
instead of editing schema.rb, please use the migrations feature。因此，如果您在一个自动生成的文件上运行db:schema:load，而您没有再次自动生成的迁移，那么您实际上是在手动“编辑”架构并废弃迁移。我希望我能从 Rails 指南中得到引用，但他们没有讨论 schema:load，这让我在决定如何使用 schema:load 功能时更加沮丧。 =/
rake db:schema:load 而不是 rake db:migrate。然后从那里，你可以rake db:migrate。
作为其他 ORM 的用户，Rails 没有“同步和更新”功能对我来说总是很奇怪。即，通过使用模式文件（代表完整的、最新的模式），遍历现有的数据库结构并根据需要添加/删除表、列、索引。
对我来说，这会更加健壮，即使可能会慢一点。
【讨论】：
schema 是 master，而不是迁移。
因为迁移可以回滚，并提供额外的功能。例如，如果您需要修改一些数据作为架构更改的一部分，那么您需要将其作为迁移来执行。
【讨论】：