我有 Rails 应用程序，每隔一段时间，当我让新的开发人员加入时，他们会惊呼他们应该能够通过运行迁移的整个历史在他们的开发环境中生成当前的数据库模式。我个人认为迁移不是您架构的权威来源。现在我们所做的是将具有当前模式的数据库的生产副本加载到开发机器上。而且，从那里，模式可以通过增量迁移来维护。
所以我的问题是：
【问题讨论】：
标签： ruby-on-rails database-schema rails-migrations
我不认为迁移是您架构的权威来源。迁移功能非常强大，但可选。一些开发人员使用替代工作流，尤其是在 DBA 坚持强引用完整性和 DBMS 强制约束的环境中。我建议查看官方的 RoR 迁移指南以获取更多信息。 db/schema.db（或db/{env}_structure.sql）文件是您的架构的权威来源。随着项目变老，许多开发人员会清除旧的迁移，因此运行每个迁移不一定会产生一个工作数据库。运行数百次迁移也需要很长时间。 Rails 使用 schema.db（或 sql 转储文件）来构建测试数据库，当然还有在运行 rake db:setup 时，这是为您的应用程序创建新数据库的推荐方式。
最重要的是rake db:setup 应该始终生成一个工作数据库，而不管迁移如何。开发人员可以使用它来创建新环境，Rails 使用它来运行您的测试。
http://guides.rubyonrails.org/migrations.html#schema-dumps-and-source-control
【讨论】：
通常，连续运行所有迁移应该会生成您的实际数据库架构（如果不是这种情况，那么您没有正确使用迁移*）。
另一种方法是复制 rake db:setup 使用的 schema.rb（迁移时创建/更新），并且应该生成您在生产中拥有的架构的精确副本（除非再次，您没有正确使用迁移*）。
然后，如果您需要“示例数据”，您可以使用 db/seeds.rb 文件插入它，该文件包含可以访问您的模型的 ruby 代码，从而创建和持久化新实体等...
*：在某些情况下，您不能以“通常”的方式将所有数据库更改放入迁移中（这种情况不常见，应尽可能避免）......但是，这些应该包含在迁移中（简而言之SQL 执行语句），或者也需要在开发数据库上手动进行更改......然后使用 prod 的快照。有时更方便。但同样，我不鼓励这样做。
【讨论】：