1

我有 Rails 应用程序，每隔一段时间，当我让新开发人员加入时，他们会惊呼他们应该能够通过运行迁移的整个历史在他们的开发环境中生成当前的数据库模式。我个人认为迁移不是您架构的权威来源。现在我们所做的是将具有当前模式的数据库的生产副本加载到开发机器上。而且，从那里，模式可以通过增量迁移来维护。

所以我的问题是：

  • Rails 项目中架构的权威来源是什么？
  • 现在认为维护数据库模式的最佳实践方法是什么？
4

2 回答 2

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

于 2011-02-14T15:22:26.537 回答
1

通常，运行所有迁移的连续性应该会产生您的实际数据库模式（如果不是这种情况，那么您没有正确使用迁移*）。

另一种方法是复制 schema.rb （在迁移时创建/更新），它被使用rake db:setup并且应该生成您在生产中拥有的模式的精确副本（除非再次，您没有正确使用迁移*)。

然后，如果您需要“示例数据”，您可以使用 db/seeds.rb 文件插入它，该文件包含可以访问您的模型的 ruby​​ 代码，从而创建和持久化新实体等...

*：在某些情况下，您不能以“通常”的方式将所有数据库更改放入迁移中（这种情况不常见，应尽可能避免）......但是，这些应该包含在迁移中（在普通 SQL 执行语句中)，或者也需要在开发数据库上手动进行更改......然后使用 prod.snapshot 的快照。有时更方便。但同样，我不鼓励这样做。

于 2011-02-14T15:11:47.727 回答