我们在讨论回退保险策略时，常常会听到客户认同回退策略，但认为从技术上来说，回退是不可行的。对于这个质疑，我们的回答是，从技术上说，几乎一定可以进行回退，只是你当前的团队、流程和架构不能实现回退罢了。

我们在讨论回退保险策略时，常常会听到客户认同回退策略，但认为从技术上来说，回退是不可行的。对于这个质疑，我们的回答是，从技术上说，几乎一定可以进行回退，只是你当前的团队、流程和架构不能实现回退罢了。



在基于Web的平台或者后合办公T系统中，不能回退最常见的借口是数据库模式不兼容。这种观点认为，对于主要的软件开发工作，因为它们可能会对数据库模式作出重大修改，从而使存储的新旧数据不兼容。这些修改可能会造成数据库表关系的改变、候选关键字的改变、表列的改变、表增加了、表合并了、表分解了以及表被删除了。
 
修复这种数据库问题的关键是，在扩展数据库模式的同时，保留旧的数据库关系和实体，至少在你遇到重大的性能问题需要回退到旧数据库时，仍然可以使用它们。当你出于功能或性能原因需要转移数据以创建不同范式构成的各种数据库模式时，应该考虑使用由数据库触发的数据转移程序，或者使用一个数据转移后台程序或第三方的复制技术。当你达到或者超出了需求中指定的回退版本个数时，这种数据转移就会停止。在理想状况下，在实施了变更后的一周或两周内，验证了你不需要回退后，就可以关闭这种数据转移系统。

在理想状况下，你会限制这种数据转移，而是把新数据写人新的数据库表或列中，而让旧数据留在原有的数据库表和列中。在很多情况下，这种方法都能满足你的需求。当你需要重组数据时，只需把在执行回退的时间段中的微信小程序数据从新的位置转移回旧的位置即可。如果你需要改变数据库中一列的名字或者它在应用中的含义，那么首先应该撇开数据库，修改应用，然后再在将来发布新版本时，修改数据库。这是回退一般原则的一个例子，即在一个发布版本中修改应用，在之后的另一次发布中，再修改数据库。