我有Rails应用程序，每隔一段时间，当我带来新的开发人员时，他们会惊叹他们应该能够通过运行整个迁移历史记录在他们的开发环境中生成当前的数据库模式。我个人认为迁移不是您架构的权威来源。现在我们所做的是将具有当前模式的DB的生产副本加载到开发机器上。并且，从那里，可以通过增量迁移来维护模式。
所以我的问题是：
答案 0 :(得分：6)
我不认为迁移是您的架构的权威来源。迁移功能非常强大但可选。一些开发人员使用替代工作流，尤其是在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
答案 1 :(得分：1)
通常情况下，运行所有迁移的连续性应生成实际的数据库架构（如果不是这种情况，那么您没有正确使用迁移*）。
另一种方法是复制schema.rb（在迁移时创建/更新），由rake db:setup使用，并且应该生成您在生产中使用的模式的精确副本（除非，再次，你没有正确使用迁移*）。
然后，如果您需要“示例数据”，则可以使用db / seeds.rb文件插入它，该文件包含可以访问模型的ruby代码，从而创建并保留新实体＆amp;等......
*：在某些情况下，您无法以“通常”的方式将所有数据库更改放入迁移中（这种情况并不常见，应尽可能避免）...这些应该包含在迁移中（但是SQL执行语句），或者需要在dev DB上手动进行更改......然后使用prod的快照。有时更方便。但同样，我不鼓励这样做。