rake db：schema：load与迁移

这是一个非常简单的问题-如果应用程序变得越来越复杂，迁移会变得缓慢而麻烦，并且如果我们可以rake db:schema:load调用更清洁的方法，那么为什么根本不存在迁移呢？

如果上面的答案是迁移用于版本控制（逐步记录对数据库的更改），那么随着应用变得越来越复杂且rake db:schema:load使用量越来越大，它们是否继续保持其主要功能？

警告：

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

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

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

附带说明一下，我坚信绝对不要将数据创建放在迁移文件中。该seed.rb文件可用于此或自定义耙或部署任务。将其放入迁移文件中会使数据库架构规范与数据规范混合在一起，并且在运行迁移文件时可能导致冲突。

刚刚偶然发现这篇帖子，那是很久以前的事了，没有看到我期望的答案。

rake db:schema:load第一次将系统投入生产是很棒的。之后，您应该正常运行迁移。

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

通过迁移，您也可以将数据添加到数据库。但是db：schema：load仅加载架构。

因为迁移可以回滚，并提供其他功能。例如，如果您需要在架构更改中修改某些数据，则需要作为迁移来进行。

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

对我来说，这可能会更健壮，即使可能慢一点。

我已经将其发布为评论，但是最好将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文件中。

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

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

您可以在此处找到有关rake数据库命令的更多信息。