当我在我的应用程序*(s) 上进行迭代时，我积累了迁移。截至目前，共有 48 个此类文件，跨越大约 24 个月的事件。
我正在考虑采用我当前的 schema.rb 并将其作为基线。
我也在考虑删除(当然，受源代码控制)现有的迁移并从我当前的模式创建一个漂亮的 Shiny 的新单一迁移？迁移倾向于使用符号，但 rake db:schema:dump 使用字符串:我应该关心吗？
这看起来合理吗？ 如果是这样，在什么样的时间间隔进行这样的练习才有意义？ 如果不是，为什么不呢？
我是否错过了一些(佣金？)可以为我完成的任务？
* 在我的例子中，所有应用程序都是基于 Rails 的，但是任何使用 ActiveRecord 迁移的应用程序似乎都符合这个问题。
最佳答案
是的，这是有道理的。有一种合并迁移的做法。为此，只需将当前模式复制到迁移中，并删除所有较早的迁移。然后您需要管理的文件更少，并且测试可以运行得更快。 您需要小心执行此操作，尤其是当您在生产环境中自动运行迁移时。我通常用新模式替换我知道每个人都运行过的迁移。
其他人的方法略有不同。
我通常在迁移超过 100 次后才这样做，但经过几个月的开发后我们可以做到这一点。但是，随着项目的成熟，迁移的频率越来越低，因此您可能不必再做一次。
这确实违背了最佳实践:一旦您 checkin 到源代码管理的迁移，就不要更改它。如果其中有错误，我会罕见异常(exception)，但这种情况非常罕见(可能是 100 分之一)。原因是一旦它们出现在野外，有些人可能已经运行了它们。它们在数据库中被记录为已完成。如果您更改它们并 checkin 新版本，其他人将无法从更改中获益。您可以要求人们回滚某些更改，然后重新运行它们，但这违背了自动化的目的。经常做，它变得一团糟。最好一个人呆着。
关于ruby-on-rails - 何时(如果)合并 ActiveRecord 迁移？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1486514/