Gre*_*ech 5 database migration
由于所有数据库都应该是,我们的源代码使用源代码控制进行版本控制.使用由Red Gate的比较工具生成的一系列SQL脚本升级数据库,这与在最近涌现的众多数据库迁移框架中的"向上"迁移基本相同.
但是这些框架中"向下"迁移的重点是什么？通常,"向上"迁移的代码非常复杂(通常随着功能的发展而进行复杂的数据迁移),我很难看到为"向下"迁移而必须反向编写它的目的.这当然是我从未感受到的东西.我在这里错过了什么......？
这里的相关问题似乎是:
我可以想到几个原因:
数据库非常大 - 比如几百GB - 并且您的公司无法承担完全恢复所涉及的停机时间和/或管理开销.
引入了一个错误,直到生产一到两周才发现.如果您以前从未体验过这一点,那么您很幸运.一旦您在新数据库中获得了一周的交易,您就可以忘记从备份中恢复.
直到发布数月才发现该错误.换句话说,您甚至不再拥有备份,而且您正式处于损害控制/灾难恢复模式.我从来没有经历过这个,但我听过故事.这是一个可怕的想法 - 你如何撤消所做的所有损害？在这种情况下,您的降级可能并不完美,但它可能仍然比替代方案更好.
相比之下,数据库更改可能是微不足道的 - 在这里添加几行,在那里添加一些触发器.在这种情况下,脚本化回滚将比恢复花费更少的时间.一些花费数小时升级的事情 - 例如创建新索引或添加新列 - 可能只需要几秒钟来降级(丢弃).
您正在部署到客户站点.他们中的一些可能根本没有备份(是的,这很可怜,但你无能为力).如果其中一个需要回滚,这是您唯一的选择.
降级脚本可能还有其他原因 - 这只是我的头脑.