数据库迁移“向下”有什么意义？答案

【问题标题】：What is the point of database migrations 'down'?数据库迁移“向下”有什么意义？
【发布时间】：2010-01-08 00:05:16
【问题描述】：

与所有数据库一样，我们的源代码使用源代码控制进行版本控制。数据库使用 Red Gate 的比较工具生成的一系列 SQL 脚本进行升级，这与最近似乎如雨后春笋般涌现的众多数据库迁移框架中的“向上”迁移基本相同。

但是这些框架中“向下”迁移的意义何在？通常，“向上”迁移的代码非常复杂（通常是随着功能的发展而进行复杂的数据迁移），我很难看出必须为“向下”代码反向编写所有代码的目的。这当然是我从未感到需要的东西。我在这里错过了什么吗...？

【问题讨论】：

【解决方案1】：

看来这里的相关问题是：

我能想到几个原因：

数据库非常大 - 比如说几百 GB - 您的公司无法承受完全恢复所涉及的停机时间和/或管理开销。
引入了一个错误，直到投入生产一两周后才被发现。如果您以前从未经历过这种情况，那么您很幸运。一旦您在新数据库中获得了一周的交易量，您就可以忘记从备份中恢复。
直到发布个月后才发现该错误。换句话说，您甚至没有备份，并且您正式处于损坏控制/灾难恢复模式。我从来没有经历过这种事，但我听过故事。这是一个可怕的想法——你如何消除所有造成的伤害？在这种情况下，您的降级可能并不完美，但仍可能比替代方案更好。
相比之下，数据库更改可能是微不足道的 - 在此处添加几行，在此处添加一些触发器。在这种情况下，脚本回滚将比恢复花费多少的时间。一些需要花费数小时才能升级的事情（例如创建新索引或添加新列）可能只需要几秒钟即可降级（删除）。
您正在部署到客户站点。其中一些可能根本没有备份（是的，这很可悲，但您无能为力）。如果其中一个需要回滚，这是您唯一的选择。

降级脚本可能还有其他原因 - 这只是我的想法。

【讨论】：

【解决方案2】：

客户：“我们不喜欢新版本，想回到旧版本。”

【讨论】：

【解决方案3】：

【讨论】：

至于#1，我们发现升级前备份通常是更好的做法。
但是对于 (1)，您肯定已经很好地测试了它，完成了许多部署测试，并测试了数据库的备份/恢复；当然，在部署之前恢复最后一个已知良好的数据库比运行代码要好，毕竟如果 up 失败，那么为什么 down 会更好呢？还有（2）为什么不从以前的版本基线开始，只应用与你的分支相关的脚本呢？这就是我们所做的，而且效果很好......
当然，在生产中进行任何更改之前，您应该始终备份您的数据库。使用迁移回滚可能比执行完整的数据库还原更快（同时仍保留在备份和还原点之间更改的数据）。一些系统广泛使用迁移，它是框架的一部分（例如 rails），所以这就是您进行开发的方式。当然还有其他方法可以实现。但是，如果您将迁移用于上升，为什么不将它们也用于下降呢？保持相同的系统，使用做得好的工具，等等......

【解决方案4】：

如果您进行升级，然后将要保留的数据添加到数据库中，则回滚脚本（只要它是这样设计的）应该可以实现此目的，而如果您只是恢复备份，则会丢失它.

但您可以通过恢复备份并使用 SQL 数据比较复制其他数据来解决上述问题。

【讨论】：