管理将破坏性数据库更改迁移到由同一应用程序的旧版本共享的数据库

Posted 2023-05-08

【中文标题】管理将破坏性数据库更改迁移到由同一应用程序的旧版本共享的数据库

【英文标题】：Managing the migration of breaking database changes to a database shared by old version of the same application

【发布时间】：2008-11-02 16:49:29

【问题描述】：

我的目标之一是能够部署与旧版本并行运行的新版本 Web 应用程序。问题是所有东西都共享一个数据库。新版本中的数据库倾向于对数据库表进行重大重构。我希望随着时间的推移向用户推出新版本的应用程序，并在需要时将它们切换回旧版本。

Oren 有一个很好的 post 设置问题，但它以：

“对于影响整个系统的更改，即破坏数据库更改，在部署到生产环境方面，我们仍然处于混乱之中。我将在下一部分中讨论这个问题，这只是一个恐怕有点失控了。”

后续帖子从未出现;-)。您将如何。您将如何保持数据同步？

【问题讨论】：

您的问题是否还包括数据库更改部署？

【参考方案1】：

阅读 Scott Ambler 的书《Refactoring Databases》；加点盐，但里面有很多好主意。

可用解决方案的详细信息取决于您使用的 DBMS。但是，您可以执行以下操作：

为新设计创建一个新表（或多个新表） 使用旧表名创建一个视图，从新表中收集数据 在视图上创建“instead of”触发器以更新新表而不是视图

在某些情况下，您不需要新表 - 您可能只需要触发器。

【参考方案2】：

如果必须维护旧版本，那么更改就不会中断。这在部署新版本的 Web 应用程序时也很有帮助 - 如果您需要回滚，真的如果您可以保留数据库原样，它会很有帮助。

显然，这会带来重大的架构障碍，并且您几乎可以肯定最终会得到一个显示其血统的数据库，可以这么说 - 但根据我的经验，部署优势通常值得头疼。

如果您为所涉及的每个旧版本都收集了可靠的集成测试，这将很有帮助。您应该能够针对仍被视为“可能实时”的每个版本的迁移测试数据库运行它们 - 在某些情况下，这很可能是“曾经的每个版本”。如果您能够合理地严格控制部署，则可能只具有三个或四个版本的兼容性 - 在这种情况下，如果确实需要，您可以计划逐步淘汰过时的表/列等。请记住，针对所产生的收益进行此类规划的复杂性。

【参考方案3】：

假设您的客户端只有 2 个版本，我只会在新表中保留一份数据副本。

您可以在新表之上的视图背后维护新旧应用之间的契约。 使用之前/而不是触发器来处理写入实际写入新表的“旧”视图。

您正在维护 2 个版本的代码，并且仍必须开发您的旧应用，但这是不可避免的。

这样，没有同步问题，实际上您必须处理“旧”和“新”模式之间的复制冲突。

如前所述，超过 2 个版本变得复杂...

【参考方案4】：

首先，我想说这个问题非常难，你可能找不到完整的答案。

最近我一直在维护一个遗留的业务线应用程序，该应用程序可能很快会演变为新版本。维护包括解决错误、优化旧代码和新功能，这些功能有时无法轻松适应当前的应用程序架构。我们的应用程序的主要问题是它的文档记录很差，没有任何更改的痕迹，而且我们基本上是从事这个项目的第 5 个轮换团队（我们对它还很陌生）。

将外部细节放在一边（代码、层等），我将尝试解释一下我们当前如何管理数据库更改。

目前我们有两条规则要遵守：

首先，旧代码（sql、存储过程、函数等）是否按原样工作并且应该保持原样，除非有这种情况（错误或功能更改），否则不要修改太多，并且当然，尽量把它记录下来（尤其是像这样的问题： “WTF！，他为什么要那样做而不是那样做？”）。

其次，每一个新特性的出现都应该使用目前已知的最佳实践，并尽可能少地修改旧的数据库结构。这将引入一些数据库重构选项，例如在旧结构之上使用可编辑视图、为现有的扩展表引入新的扩展表、规范化结构并通过视图提供旧结构等。

此外，我们正在尝试编写尽可能多的单元测试，前提是业务分析师并肩工作并记录业务规则。

数据库重构是一个非常复杂的领域，需要简短回答。有很多书可以回答你所有的问题，one http://databaserefactoring.com/ 被指向answers 之一。

稍后编辑：希望第二条规则也能回答对重大更改的处理。