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

好吧,这是我们面临的问题。

目前:

>我们有大量的Legacy应用程序可以直接访问数据库
>数据库中的数据结构不正常化
>几乎所有应用程序都使用当前的进程/结构

我们正在努力实现:

>将所有功能移动到RESTful服务,以免任何应用程序都有直接的数据库访问
>实现规范化的数据结构

我们遇到的问题是如何实现这种迁移不仅与应用程序,而且与数据库。

我们目前的解决方案是:

>识别所有的CRUD功能,并在新的Web Service中实现
>创建新的应用程序来替换旧版应用程序
>将新应用程序指向新的Web服务(仍指向旧的数据结构)
>将数据库中的数据迁移到新的“结构”
将新应用程序指向新的Web服务(指向新的数据结构)

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

我想知道有没有人面临过这样的挑战,你们是如何克服这些类型的问题/实现的呢?

最佳答案
编辑:使用双向触发器更多地说明同步;更新语法,语言和清晰度。

前言

在我工作了7年的大型Web应用程序的数据模型升级中,我遇到了类似的问题,所以感觉到你的痛苦。从这个经验来看,我会提出一些有些不同的东西,但希望能够更容易实现。但首先,一个观察:

数据的价值是数据 – 数据将长期超过您当前的所有应用程序。业务将不断发明新的方法,从获取的数据中获取价值,从而产生新的报告,应用程序和业务方式。

所以得到新的数据结构应该是你最重要的目标。不要将结构交易反对其他短期发展目标,特别是:

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

这种结构将随着时间的推移而改变,因此您的架构必须允许频繁添加和不频繁的规范化。这意味着您的数据结构和任何共享API(包括RESTful服务)必须正确版本化。

为什么选择RESTful Web服务?

你提到你的“将所有的功能都移植到一个RESTful的服务,所以没有应用程序有直接的数据库访问”。我需要问一个关于遗留应用程序的一个非常重要的问题:为什么这是重要的,它带来了什么价值?

我问:

>您失去ACID事务(每次调用都是单个事务,除非您实现了一些令人难以置信的复杂的WS- *标准)
>性能下降:直接数据库连接速度将更快(无需Web服务器的工作和转换),延迟时间较短(通常为1ms,而不是50-100ms),这将明显降低直接DB连接应用程序的响应速度
>数据库结构没有从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服务的诋毁,特别是RESTful Web服务。当用于正确的原因,例如启用Web应用程序或不同系统之间的集成时,这是一个很好的架构解决方案。但是,在数据迁移期间可能不是管理旧版应用程序的最佳解决方案。

转载注明原文:数据库 – 从旧数据结构到新数据结构的数据迁移 - 代码日志