database - 数据库迁移 'down' 有什么意义？

Question

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

但是这些框架中的“向下”迁移有什么意义呢？通常，“向上”迁移的代码非常复杂(通常是随着功能的发展而进行的复杂数据迁移)，我很难理解为“向下”迁移而必须将其全部反向编写的目的。这当然是我从未觉得需要的东西。我在这里错过了什么......？

Answer 1

看来这里的相关问题是:

• 为什么脚本回滚比从升级前立即备份的完整数据库恢复更可取？

我能想到几个原因:

1. 数据库非常大 - 比如说几百 GB - 贵公司无法承受完全恢复所涉及的停机时间和/或管理开销。

2. 引入了一个错误，该错误直到投入生产一两周后才被发现。如果您以前从未经历过这种情况，那么您很幸运。一旦您在新数据库中获得了一周的交易量，您就可以忘记仅仅从备份中恢复。

3. 直到发布 个月 后才发现错误。换句话说，您甚至不再备份，并且您正式处于损害控制/灾难恢复模式。我从未经历过这种情况，但我听说过这样的故事。这是一个可怕的想法——你如何消除所有已经造成的伤害？在这种情况下，您的降级可能并不完美，但它可能仍然比替代方案更好。

4. 相比之下，也许数据库更改微不足道 - 在这里添加几行，在那里添加一些触发器。在这种情况下，脚本回滚将比恢复花费的时间多。某些需要数小时才能升级的内容(例如创建新索引或添加新列)可能只需要几秒钟就可以降级(丢弃)。

5. 您要部署到客户站点。其中一些可能根本没有备份(是的，这很可悲，但您对此无能为力)。如果其中之一需要回滚，这是您唯一的选择。

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