Question

这里有一个非常简单的问题 - 如果应用程序变得更加复杂，并且如果我们有更清晰的rake db:schema:load来调用，那么迁移会变得缓慢而繁琐，为什么迁移依然存在呢？

如果上述答案是迁移用于版本控制（数据库更改的逐步记录），那么当应用程序变得更复杂并且更多地使用rake db:schema:load时，它们是否继续保持他们的主要功能？

注意：

从这个问题的答案：rake db:schema:load 将删除生产服务器上的数据，因此在使用时要小心。

Answer 1

迁移提供对数据库的前向和后退步骤更改。在生产环境中，必须在部署期间对数据库进行增量更改：迁移为此功能提供回滚故障保护。如果在生产服务器上运行rake db:schema:load，则最终会删除所有生产数据。这是一个危险的习惯。

话虽如此，我认为偶尔“崩溃”迁移是一种不错的做法。这需要删除旧的迁移，将其替换为单个迁移（非常类似于您的schema.rb文件）并更新schema_migrations表以反映此更改。 这样做时要非常小心！如果不小心，可以轻松删除生产数据。

作为旁注，我坚信您绝不应该将数据创建放在迁移文件中。 seed.rb文件可用于此任务或自定义rake或部署任务。将此文件放入迁移文件会将数据库架构规范与数据规范混合在一起，并在运行迁移文件时导致冲突。

Answer 2

刚刚发现这篇文章，很久以前，并没有看到我期待的答案。

第一次将系统投入生产时，

rake db:schema:load非常棒。之后，您应该正常运行迁移。

这也可以帮助您随时清理迁移，因为即使清理了迁移，架构也可以将所有其他计算机投入生产。

Answer 3

迁移还允许您向数据库添加数据。但是db：schema：load只加载模式。

Answer 4

因为可以回滚迁移，并提供其他功能。例如，如果您需要修改某些数据作为架构更改的一部分，那么您需要将其作为迁移来执行。

Answer 5

作为其他ORM的用户，Rails没有“同步和更新”功能对我来说似乎总是很奇怪。即，通过使用模式文件（表示整个最新模式），遍历现有数据库结构并根据需要添加/删除表，列，索引。

对我而言，即使可能稍微慢一些，这也会更加强大。

Answer 6

我已发布评论，但感觉最好将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文件中会更好......

Answer 7

rake db:migrate设置数据库中的表。当您运行迁移命令时，它将在db / migrate /中查找任何ruby文件，并从最旧的文件开始执行它们。每个迁移文件名的开头都有一个时间戳。

与运行尚未运行的迁移的rake db:migrate不同，rake db:schema:load会将db/schema.rb中已生成的架构加载到数据库中。

您可以找到有关rake database commands here的更多信息。

rake db：schema：load vs. migrations

注意：

7 个答案: