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

Question

好的,这就是我们面临的问题.

目前:

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

我们正在尝试实施的内容:

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

我们遇到的问题是如何不仅使用Applications而且使用数据库实现此迁移.

我们目前的解决方案是:

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

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

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

Answer 1

编辑:使用双向触发器进行更多同步说明; 更新语法,语言和清晰度.

前言

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

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

因此,正确地获得新数据结构应该是您最重要的目标.不要将结构与其他短期发展目标进行交易,尤其是:

• 运营目标,例如推出新服务
• 报告性能(使用物化视图,触发器或批处理作业)

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

为什么RESTful Web服务？

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

我问因为:

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

其他跨领域问题没有改变:

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

您可以通过维护旧版RESTful API来迁移数据库并使旧版应用程序保持运行.但是,如果我们可以在不引入"遗留"RESTful服务的情况下保留旧版应用程序,该怎么办

数据库版本控制

据推测,大多数"遗留"应用程序使用SQL直接访问数据表; 您可能还有许多数据库视图.

数据迁移的一种方法是新数据库(在新模式中具有新的规范化结构)将旧结构呈现为遗留应用程序的视图,通常来自不同的模式.

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

• 简单转换的可更新视图
• 引入无法更新视图的存储过程(例如"CALL insert_emp(？,？,？)"而不是"INSERT INTO EMP(col1,col2,col3)VALUES(？,？？)".
• 拥有一个"遗留"表,该表与触发器和数据库链接的新数据库同步.

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

您最终会在两个不同的模式(或数据库)中使用相同的数据,并且如果同步代码存在错误,则数据可能会失去同步 - 然后您就会遇到"两个主要"问题的经典问题.因此,将此视为最后的手段,例如:

• 基本结构已经改变(例如改变关系的基数),或者
• 对遗留格式的转换是一个复杂的函数(例如,如果遗留列是新格式列值的平方并且设置为"4",则可更新视图无法确定正确的值是+2还是-2) .

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

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

它还允许您专注于组织的真正价值:

• 新的数据库结构
• 新的RESTful Web服务
• 新应用程序(可能使用RESTful Web服务构建)

Web服务的积极方面

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