Database 从旧数据 struct 到新数据 struct 的数据迁移

EDIT:更多关于使用双向触发器进行同步的解释；语法、语言和清晰度的更新.

前言

在我工作了7年的大型Web应用程序的数据模型升级过程中，我也遇到过类似的问题，所以我能感受到您的痛苦.从这次经验中，我会提出一些不同的东西-但希望这个东西更容易实现.但首先，我要说的是:

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

因此，正确使用新的数据 struct 应该是您最重要的目标.不要将 struct 与其他短期发展目标进行权衡，尤其是:

• 运营目标，如推出新服务
• 报告性能(改用实体化视图、触发器或批处理作业(job))

此 struct 将随着时间的推移而更改，因此您的体系 struct 必须允许频繁添加和不频繁的规范化.这意味着您的数据 struct 和它的任何共享API(包括REST风格的服务)必须有正确的版本.

为什么 Select REST风格的Web服务？

您提到您将"将所有功能转移到REST风格的服务，这样应用程序就不能直接访问数据库".关于遗留应用，我需要问一个非常重要的问题:为什么这很重要？它带来了什么价值？

我这样问是因为:

• 您会丢失ACID事务(每个调用都是一个事务，除非您实现了一些极其复杂的WS-*标准)
• 性能下降:直接数据库连接速度更快(无需web服务器工作和翻译)，延迟更少(通常为1ms，而不是50-visiblyms)，这将降低为直接数据库连接编写的应用程序的响应速度
• 数据库 struct 不是从RESTful服务中抽象出来的，因为您承认，通过数据库规范化，您必须重写web服务并重写调用它们的应用程序.

其他交叉关注的问题也没有改变:

• 可管理性:直接数据库连接可以通过许多通用工具进行监控和管理
• 安全性:直接连接比您的开发人员将编写的Web服务更安全，
• 授权:数据库权限模型非常先进，并且细粒度与您想要的一样
• 可伸缩性:web服务是一个(唯一的？)直接连接的数据库应用程序，因此只能与数据库一样扩展

通过维护传统RESTful API，您可以迁移数据库并保持传统应用程序运行.但是，如果我们可以让遗留应用程序without继续引入"遗留"RESTful服务，会怎么样呢？

数据库版本控制

想必大多数"遗留"应用程序都使用SQL直接访问数据表；您可能也有许多数据库视图.

数据迁移的一种方法是新数据库(在新模式中具有新的标准化 struct )将旧 struct 作为views呈现给遗留应用程序，通常来自不同的模式.

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

• 用于简单转换的可更新视图
• 介绍无法更新视图的存储过程(例如"call insert_emp(？，？，？)"而不是"INSERT INTO EMP(COL1，COL2，COL3)值(？，？？)".
• 有一个"遗留"表，它通过触发器和数据库链接与新数据库同步.

使用触发器将遗留格式表与新格式表进行双向同步是一种强力解决方案，而且相当难看.

您最终会在两个不同的模式(或数据库)中获得相同的数据，并且如果同步代码有bug，数据可能会不同步-然后您就会遇到"两个主机"问题的classic 问题.因此，请将此视为最后手段，例如在以下情况下:

• 基本 struct 已更改(例如，更改关系的基数)，或者
• 到遗留格式的转换是一个复杂的函数(例如，如果遗留列是新格式列值的平方并且被设置为"4"，则可更新视图不能确定正确值是+2还是-2).

当您的数据中需要这样的更改时，代码和逻辑somewhere中将会有一些重大更改.您可以在兼容层中实现(优点:不更改遗留代码)或更改遗留应用程序(优点:数据层是干净的).这是工程团队的技术决定.

使用上述方法创建遗留 struct 的兼容性数据库，可以最大限度地减少对遗留应用程序的更改(在某些情况下，遗留应用程序在没有任何代码更改的情况下继续运行).这大大降低了开发和测试成本(这对业务没有净功能yield )，并大大降低了推出风险.

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

• 新的数据库 struct
• 新的REST风格的Web服务
• 新应用程序(可能使用RESTful web服务构建)

Web服务的积极方面

请不要将上面的内容理解为对Web服务的抨击，尤其是REST风格的Web服务.当出于正确的原因使用时，例如用于启用Web应用程序或不同系统之间的集成，这是一个很好的体系 struct 解决方案.但是，它可能不是在数据迁移期间管理旧版应用程序的最佳解决方案.