我的目标之一是能够部署与旧版本并行运行的 Web 应用程序的新版本。问题是所有东西都共享一个数据库。新版本中的数据库倾向于对数据库表进行重大重构。我希望随着时间的推移向用户推出新版本的应用程序，并在需要时将它们切换回旧版本。
Oren 有一个很好的帖子来设置这个问题，但它以：
“对于影响整个系统的更改，即破坏数据库更改，在部署到生产环境方面，我们仍然处于混乱之中。我将在下一部分中讨论这一点，这只是一点点手，我怕。”
后续帖子从未出现;-)。您将如何管理将破坏性数据库更改迁移到由同一应用程序的旧版本共享的数据库。您将如何保持数据同步？
阅读 Scott Ambler 的《重构数据库》一书；加一点盐，但里面有很多好主意。
可用解决方案的详细信息取决于您使用的 DBMS。但是，您可以执行以下操作：
在某些情况下，您不需要新表 - 您可能只需要触发器。
如果必须维护旧版本，则更改根本不会中断。这在部署新版本的 Web 应用程序时也很有帮助 - 如果您需要回滚，如果您可以保持数据库不变，这真的很有帮助。
显然，这带来了重大的架构障碍，并且您几乎可以肯定最终会得到一个显示其血统的数据库，可以这么说 - 但根据我的经验，部署优势通常值得头疼。
如果您对涉及的每个旧版本都有一个可靠的集成测试集合，这将很有帮助。您应该能够针对仍被视为“可能实时”的每个版本的迁移测试数据库运行它们 - 在某些情况下，这很可能是“曾经的每个版本”。如果您能够合理地严格控制部署，则可能只具有三个或四个版本的兼容性 - 在这种情况下，如果确实需要，您可以计划逐步淘汰过时的表/列等。请记住，这种计划对所产生的好处的复杂性。
假设您的客户端只有 2 个版本，我只会在新表中保留一份数据副本。
您可以在新表之上的视图后面维护新旧应用程序之间的合同。使用之前/而不是触发器来处理对实际写入新表的“旧”视图的写入。
您正在维护 2 个版本的代码，并且仍必须开发您的旧应用程序，但这是不可避免的。
这样，就没有同步问题，实际上您必须处理“旧”和“新”模式之间的复制冲突。
如前所述，超过 2 个版本变得复杂......
首先，我想说这个问题非常难，你可能找不到完整的答案。
最近我一直在维护一个遗留的业务应用程序，它可能很快就会演变为一个新版本。维护包括解决错误、优化旧代码和新功能，这些功能有时无法轻松适应当前的应用程序架构。我们的应用程序的主要问题是它的文档记录很差，没有任何更改的痕迹，而且我们基本上是从事这个项目的第 5 个轮换团队（我们对它还很陌生）。
将外部细节放在一边（代码、层等），我将尝试解释一下我们当前如何管理数据库更改。
目前，我们有两条规则要遵循：
首先，旧代码（sql、存储过程、函数等）是否按原样工作并且应该保持原样，除非有这种情况（错误或功能更改），否则不要修改太多，当然，尝试记录它尽可能多地（尤其是诸如“WTF！，他为什么要那样做而不是那样做？”之类的问题）。
其次，每一个新特性的出现都应该使用目前已知的最佳实践，并且尽可能少地修改旧的数据库结构。这将引入一些数据库重构选项，例如在旧结构之上使用可编辑视图，为现有的扩展表引入新的扩展表，规范化结构并通过视图提供旧结构等。
此外，我们正在尝试编写尽可能多的单元测试，前提是业务分析师并肩工作并记录业务规则。
数据库重构是一个非常复杂的领域，需要简短回答。有很多书可以回答你所有的问题，其中一本 http://databaserefactoring.com/被指出在其中一个答案中。
稍后编辑：希望第二条规则也能回答对重大更改的处理。