知识卡片
数据库迁移放弃回退功能的三个理由
内容
很多团队在做数据库迁移工具时会实现”回退”能力，但后来大多主动放弃了：一是既然所有迁移脚本都完整保留，从头重放到目标版本就能达到同样效果，没必要额外维护一条回退路径；二是维护双向正确性等于把测试成本翻倍；三是某些操作根本无法真正回退——删掉一张表之后，”回退”要么丢数据要么留一堆名存实亡的表，越搞越复杂。删除某个变更的正确方式是新增一个撤销它的迁移，而非把已应用的迁移改成可逆的。
参考来源
- 位置：《演进式架构（原书第2版）》第6章《演进式数据》6.1.1节迁移回退功能讨论（源文件：_epub-src/EPUB/xhtml/chapter10.xhtml）
- 结论依据：原文明确列出团队放弃回退功能的三个原因（从头重放即可、双向测试成本翻倍、某些操作无法真正回退），直接支持卡片论点。
- 原始内容："大多数团队已经放弃了构建回退功能的做法，原因有三个。第一，如果所有的迁移都存在，那么开发人员可以仅构建到他们需要的版本而无须回退……第二……为了更有信心地支持回退操作，开发人员必须测试代码，有时这会增加测试的负担。第三，在某些情况下构建全面的回退功能可能会带来艰巨的挑战。举个例子，想象一下在迁移中删除了一个表"