从旧数据结构到新数据结构的数据迁移

Question

好的，这就是我们面临的问题。

目前：

1. 我们有大量具有直接数据库访问权限的旧版应用程序
2. 数据库中的数据结构未规范化
3. 几乎所有应用程序都使用当前流程/结构

我们正在努力实施的目标：

1. 将所有功能移至RESTful服务，以便没有应用程序可以直接访问数据库
2. 实施规范化数据结构

我们遇到的问题是如何不仅使用应用程序而且还使用数据库实现此迁移。

我们目前的解决方案是：

1. 确定所有CRUD功能并在新的Web服务中实现此功能
2. 创建新应用以替换旧版应用
3. 将新应用程序指向新的Web服务（仍然指向旧数据结构）
4. 将数据库中的数据迁移到新的结构
5. 将新应用程序指向新的Web服务（指向新数据结构）

但是在我们讨论这个过程时，我们正在考虑两次重写New Web Service。一次用于旧数据结构，一次用于新数据结构，目前我们无法代表旧数据结构以适应新Web服务的新数据结构。

我想知道是否有人遇到过这样的挑战，你是如何克服这些类型的问题/实施等的。

Answer 1

编辑：使用双向触发器进行更多同步说明;语法，语言和清晰度的更新。

序言

我在我工作了7年的大型Web应用程序上的数据模型升级方面遇到了类似的问题，所以我感到很痛苦。根据这一经验，我会提出一些不同的东西 - 但希望能够更容易实现。但首先，观察一下：

组织的价值在于数据 - 数据将比您当前的所有应用程序都长。该企业将不断发明新的方法，从其捕获的数据中获取价值，从而产生新的报告，应用程序和开展业务的方式。

因此，正确掌握新数据结构应该是您最重要的目标。不要交易使结构与其他短期发展目标相对立，尤其是：

• 运营目标，例如推出新服务
• 报告效果（使用物化视图，触发器或批处理作业）

此结构将随着时间的推移而发生变化，因此您的体系结构必须允许频繁添加和不频繁的规范化。这意味着您的数据结构及其任何共享API（包括RESTful服务）必须正确版本化。

为什么要使用RESTful Web服务？

您提到您的意愿＆＃34;将所有功能移至RESTful服务，因此没有应用程序可以直接访问数据库＆＃34;。我需要就遗留应用程序提出一个非常重要的问题：为什么这很重要，它带来了什么价值？

我问因为：

• 您将丢失ACID事务（除非您实施一些非常复杂的WS- *标准，否则每次调用都是单个事务）
• 性能下降：直接数据库连接速度更快（没有Web服务器工作和翻译）并且具有更少的延迟（通常为1ms而不是50-100ms），这将明显降低写入的应用程序的响应速度用于直接数据库连接
• 数据库结构不是从RESTful服务中抽象出来的，因为您承认在数据库规范化的情况下，您必须重写Web服务并重写调用它们的应用程序。

其他贯穿各领域的问题没有改变：

• 可管理性：可以使用许多通用工具监控和管理直接数据库连接
• 安全性：直接连接比开发人员编写的Web服务更安全，
• 授权：数据库权限模型非常先进，并且您可以根据需要进行细化
• 可扩展性：Web服务是一个（仅？）直接连接的数据库应用程序，因此只能扩展到数据库

您可以通过维护旧版RESTful API来迁移数据库并使旧版应用程序保持运行。但是，如果我们可以保留旧版应用而不引入“遗产”＆＃39; RESTful服务。

数据库版本控制

大概是＆＃39;遗产＆＃39;应用程序使用SQL直接访问数据表;你也可能有很多数据库视图。

数据迁移的一种方法是新数据库（在新模式中使用新的规范化结构）将旧结构作为视图呈现给遗留应用程序，通常来自不同的模式。

这实际上很容易实现，但只解决报告和只读功能。遗留应用程序DML怎么样？ DML可以使用

解决

• 简单转换的可更新视图
• 介绍无法更新视图的存储过程（例如＆＃34; CALL insert_emp（？，？，？）＆＃34;而不是＆＃34; INSERT INTO EMP（col1，col2，col3）VALUES（？， ？）＆＃34;。
• 拥有遗产＆＃39;与触发器和数据库链接同步的新数据库的表。

使用触发器对新格式表进行双向同步的遗留格式表是一种蛮力的解决方案并且相对难看。

您最终会在两个不同的模式（或数据库）中使用相同的数据，并且如果同步代码存在错误，则数据可能会失去同步 - 然后您就会遇到＆＃34;两个主数据的经典问题＃34;问题。因此，将此视为最后的手段，例如：

• 基本结构已发生变化（例如更改关系的基数）或
• 对遗留格式的转换是一个复杂的函数（例如，如果遗留列是新格式列值的平方并且设置为＆＃34; 4＆＃34;，则可更新视图无法确定是否正确值为+2或-2）。

当您的数据需要进行此类更改时，代码和逻辑某处会发生一些重大更改。您可以在兼容性层中实现（优点：不更改遗留代码）或更改遗留应用程序（优点：数据层干净）。这是工程团队的技术决策。

使用上面概述的方法创建遗留结构的兼容性数据库可以最大限度地减少对遗留应用程序的更改（在某些情况下，遗留应用程序可以继续进行而不会发生任何代码更改）这大大降低了开发和测试成本（业务没有净功能增益），并大大降低了部署风险。

它还可以让您专注于组织的真正价值：

• 新数据库结构
• 新的RESTful网络服务
• 新应用程序（可能使用RESTful Web服务构建）

Web服务的积极方面

请不要将上述内容视为针对Web服务的诽谤，尤其是RESTful Web服务。当出于正确的原因使用时，例如启用Web应用程序或在不同系统之间进行集成，这是一个很好的架构解决方案。但是，它可能不是在数据迁移期间管理旧应用程序的最佳解决方案。

Answer 2

您应该做的是定义一个新的数据模型（“规范化”）并构建从规范化模型到遗留模型的映射。然后，您可以随意使用规范化的呼叫替换传统的直接呼叫。这打破了没有代码。

同时，您需要定义（cerntralized）遗留数据库API的数量，并将其映射到规范化模型。现在，您可以随意使用旧版db API上的调用替换原始的旧版db调用。这没有打破代码。

完全替换原始调用后，您可以将数据模型切换到实际标准化调用。这应该不会破坏任何代码，因为现在一切都是针对遗留的db API或规范化的db API。

最后，您可以使用使用规范化数据API的修订代码替换旧版db API调用和相关代码。这需要仔细重新编码。

要加快这一切，您需要一个自动代码转换工具来实现代码替换。

本文档似乎有一个很好的概述：http://se-pubs.dbs.uni-leipzig.de/files/Cleve2006CotransformationsinDatabaseApplicationsEvolution.pdf

Answer 3

首先，这似乎是一个非常混乱的情况，我不认为有一个“干净”的解决方案。我经历了几次类似的情况 - 他们并不是很有趣。

首先，更改客户端应用程序的工作将会非常重要 - 例如，如果基础域发生更改（例如，通过引入与人员分离的地址的概念），客户端应用程序也会发生变化 - 这不是只是改变了访问数据的方式。避免这种痛苦的最好方法是编写API层以反映未来的业务领域模型，并将旧的数据库模式粘合到其中;如果有新概念无法使用旧数据反映（例如“get / app / addresses / addressID”），则抛出NotImplemented错误。如果您可以使用旧数据反映新模型，请尽可能将其连接在一起，然后重新考虑因素。

其次，这意味着您需要在API中构建版本作为一流的关注点 - 因此您可以告诉客户端在版本1中，功能x，y和z会抛出“NotImplemented”异常。每个版本都应向后兼容，但添加新功能。这样，只要您不破坏服务，就可以在版本1中重构功能，并在版本1.1中实现功能x，在版本1.2中实现功能y等。理想情况下，为您的版本制定路线图，并通知客户端应用程序所有者如果您要停止支持某个版本，或者发布重大变更。

第三，对API进行一系列自动化集成测试是您可以做出的最佳投资 - 他们确认您在重构时没有破坏功能。

希望这有一些用处 - 我认为对你的问题没有一个直截了当的答案。