在Ruby on Rails中重构数据库迁移

Question

当项目增长时，迁移的数量开始变得相当高，当我回头看时，我看到许多可以重构的迁移。如将create_posts和rename_posts_to_responses合并为create_responses。

这是一个坏习惯，还是我应该鼓励重构迁移？

Answer 1

你可能会，但是，在项目的后期，你不应该真正的运行迁移，你应该是schema:load'ing，也就是说，如果你需要启动一个全新的项目实例。根据我的经验，你会让自己比其他任何事情都更令人头疼。

但是，如果将数据包含在迁移中（发生在我们当中的最佳状态），那么执行schema:load会有点困难。

Answer 2

我见过大型项目，其中所有的迁移都被一个迁移所取代，取自schema.rb。这是不使用数据迁移的另一个原因，而是维护一组种子数据。

Answer 3

在我看来，这是正常的发展过程中重构[虽然我作为一个团队的一部分工作时，特别是劝阻]，但它通过重构迁移

Answer 4

太容易乱了生产应用程序一旦你检查迁移到源代码管理，我会建议不要改变它们。如果有一个bug存在，我会发生一个罕见的异常，但这种情况非常罕见（100个中有1个）。

原因是，一旦他们出现在野外，有些人可能已经跑了他们。他们被记录为在数据库中完成。如果您更改并检入新版本，其他人将无法从中获益。您可以让人们回滚某些更改，然后重新运行它们，但这会破坏自动化的目的。经常做，它变得一团糟。最好独自一人。

当你得到大量的迁移时，它可能开始感到尴尬。但总的来说，你不会那么做。我们唯一能做的就是在我们的集成服务器上，每次运行都会删除并重新创建数据库。所以你可以不打开那个目录并假装他们不在那里。

有一种合并迁移的做法。为此，只需将当前模式复制到迁移中，然后删除所有先前的迁移。然后您可以管理更少的文件，并且测试运行得更快。你需要小心这样做，特别是如果你在生产中自动运行迁移。我通常会替换一个我知道每个人都使用新模式运行的迁移。其他人有不同的方式来做到这一点。