数据库独立数据迁移

Question

我的目标是为现有应用程序启用模式和数据迁移.

这种问题似乎已被多次提出,但我认为有不同的要求和情况.

由于我在这个领域缺乏经验,请允许我首先列出应用程序的架构和我的假设.

建筑

该应用程序是一个多用户企业桌面应用程序,具有后端服务器,可以持久保存到任何主要数据库(MySql,Postgresql,SQL Server,Oracle DB等).假设数据库是内部部署并由我们的客户维护.

使用的技术堆栈是一个相当常见的Hibernate + Spring + RMI/JMS-Combo.

目前,服务器通过以下方式完成迁移:

• 在服务器启动时,它会检查最新的预期架构版本
• 如果大于当前版本,请开始迁移到下一版本,直到current == latest:
  1. 创建新数据库
  2. 加载(整个)最新模式(SQL脚本有很多CREATE TABLE ...)
  3. 迁移数据(在Java类中使用2个JDBC-Connections到新旧模式)
  4. 加载(所有)最新约束(SQL脚本有很多ALTER TABLE ...)

此迁移速度缓慢且仅向前.但这很简单.问题是,到目前为止,模式脚本和数据迁移中的查询一直在使用MySQL语法和功能.

请注意,通过迁移数据,我的意思是:后端服务器将数据从旧模式复制到新模式,必要时进行转换.此外,迁移过程在我们的客户端内部自动启动.意思是,我们只能控制JDBC连接,但不能直接访问数据库,也不了解正在使用的特定数据库(MySQL,SQL Server,...).

目标是用独立于数据库的迁移方案替换或扩充此迁移方案.

假设和研究

StackOverflow 1 2 3 4 5 6 7:回答状态使用Hibernate的内置功能.但是,文档声明这不是生产准备.此外,AFAICT,所有答案仅涉及架构迁移.

Liquibase:使用自定义DSL(在XML/JSON/YAML/etc中),仅允许数据库无关的模式迁移.

DBUnit:使用自定义XML-DSL捕获数据库状态的快照.无法重新创建架构版本1到版本2的快照.

飞路:原则上同Liquibase.但不是数据库独立的,因为SQL-Scripts用于迁移.

JOOQ:基于JDBC的Java中独立于数据库的Query-DSL.可与Criteria API相媲美,但没有JPA的缺点.原则上应该允许数据库独立的数据迁移,但是对于模式迁移没有帮助.

JPA-Query语言如HQL,JPQL,Criteria API是不够的,因为

1. 无法引用未由实体管理器映射的表.例如,连接表,元数据和审计表.
2. 需要保留所有版本的Entity类的副本以进行映射.

题

我意识到,现在这个问题已经存在,它将被视为以意见为基础.

但是,我不一定在寻找这个问题的具体解决方案(我怀疑对于这样一个复杂的问题空间存在明确的解决方案),而是要验证我的假设.

也就是说,这是真的

• Liquibase和Flyway主要关注架构迁移,数据迁移是留给读者的练习吗？
• 为了让Flyway支持多个不同的数据库,需要为每个数据库复制迁移脚本吗？
• 总的来说,数据库无关的数据迁移问题在企业Java中仍未解决？

即使我是Liquibase /迁飞与JOOQ结合起来,我不知道如何执行数据迁移,因为Liquibase /迁飞迁移数据库到位.旧数据库被破坏,并有机会将旧数据转换为新模式.

感谢您的关注!

Answer 1

让我们把它分解一下。你是对的，这很大程度上是基于意见的，但这是我在我的经历中注意到的。

Liquibase和Flyway主要关注模式迁移，数据迁移留给读者作为练习？

您可以使用liquibase和flyway进行数据迁移。这是我经常做的事情。以我想将用户表拆分为用户表和地址表为例。我会编写一个迁移脚本（基本上只是一个 sql 文件）来创建新的地址表并将所有相关数据复制到其中。

为了让 Flyway 支持多个不同的数据库，需要为每个数据库复制迁移脚本吗？

可能，flyway 和 liquibase 更适合作为数据库版本控制工具。如果我的应用程序需要版本 10 的数据库，这些工具将帮助我实现这一点。同样，迁移脚本只是基本的 .sql 文件。如果您正在使用一些 mysql 特定函数，那么这些函数只会进入迁移脚本，并且它们无法在 sql 服务器上运行

总的来说，企业Java中独立于数据库的数据迁移问题仍然没有解决？

呃，这个我不太清楚。我同意这是一个问题，但实际上这并不是一个大问题。在过去的 8 年多里，我只写过 ansi sql。它应该可以随身携带。因此从理论上讲，我们可以将这些应用程序转移到不同的数据库上。JPA 和各种实现有助于解决这些差异。根据您的项目的构建方式，假设一个应用程序的所有业务逻辑都在实现特定的 sql 函数中，那么这将是一个令人头痛的问题。如果您将数据库用于 CRUD，并且我认为这就是您应该使用它的全部目的，那么这并不是什么大问题。

综上所述，我认为您可能对 Flyway 和 liquibase 有错误的想法。正如我之前所说，它们并不是真正的“迁移工具”，而是数据库版本控制工具。通过订购的特定 SQL 迁移脚本列表，我可以保证任何版本的数据库状态。我不确定这些是我用来将基于 SQL Server 的旧应用程序“迁移”到基于 PostGres 的应用程序的工具。