独立于数据库的数据迁移

Question

我的目标是为现有应用程序启用架构和数据迁移。

这种问题似乎已经被问过很多次了，不过我想是因为不同的要求和环境。

由于我在这个领域没有经验，请允许我先介绍一下应用程序的架构和我的假设。

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

使用的技术堆栈是一个相当常见的Hibernate Spring RMI/JMS组合。

目前，迁移由服务器通过以下方式完成：

• 在服务器启动时，它会检查最新的预期模式版本
• 如果大于当前版本，开始迁移到下一个版本，直到当前==最新：
  1. 创建新数据库
  2. 加载（整个）最新模式（SQL脚本，其中包含大量CREATE TABLE…）
  3. 迁移数据（在Java类中使用2个JDBC-Connections到新旧模式）
  4. 加载（所有）最新约束（SQL带有大量ALTER TABLE…的脚本）

这种迁移速度很慢，而且只能向前迁移。但这很简单。问题是，到目前为止，数据迁移中的模式脚本和查询一直使用MySQL语法和特性。

请注意，通过迁移数据，我的意思是：后端服务器将数据从旧架构复制到新架构，并在必要时对其进行转换。此外，迁移过程会自动在客户端内部启动。这意味着，我们只能控制 JDBC 连接，但不能直接访问数据库，也不能了解正在使用的特定数据库（MySQL、SQL Server,...）。

目标是用一个独立于数据库的迁移方案来替换或扩充这个迁移方案。

堆栈溢出 1 2 3 4 5 6 7：使用Hibernate内置功能的答案状态。但是，文档指出这尚未准备好生产。此外，AFAICT，所有答案仅与架构迁移有关。

Liquibase：使用自定义DSL（XML/JSON/YAML/etc）仅允许独立于数据库的模式迁移。

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

flyway:原则上与Liquibase相同。但不是独立于数据库的，因为SQL脚本用于迁移。

JOOQ：一个独立于数据库的查询-DSL，位于JDBC之上的Java之上。与标准 API 相当，但没有 JPA 的缺点。原则上应该允许独立于数据库的数据迁移，但是，对架构迁移没有帮助。

HQL、JPQL、Criteria API等JPA-Query语言是不够的，因为

< li >不能引用实体管理器未映射的表。例如连接表、元数据和审计表。 < li >需要为映射保留实体类的所有版本的副本。

我意识到，就目前的情况而言，这个问题将被视为基于意见的问题。

然而，我不一定是在寻找这个问题的具体解决方案（我怀疑对于如此复杂的问题空间是否存在明确的解决方案），而是为了验证我的假设。

也就是说，这是真的吗

< li>Liquibase和Flyway主要关注模式迁移，数据迁移留给读者做练习。 < li >为了使Flyway支持多个不同的数据库，需要为每个数据库复制迁移脚本？ < li >总的来说，数据库无关的数据迁移问题在enterprise Java中仍然没有解决？

即使我将液基库/飞行路线与JOOQ结合使用，我也不知道如何执行数据迁移，因为图书馆/飞行路线迁移数据库已就地。旧数据库被破坏，并有机会将旧数据转换为新架构。

感谢您的关注！

Answer 1

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

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

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

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

可能，flyway和liquibase被认为是更好的数据库版本管理工具。如果我的应用程序需要数据库的版本10，这些工具将帮助我达到这一点。同样，迁移脚本只是基本的。sql文件。如果您正在使用一些mysql特定的函数，那么这些函数将会直接进入迁移脚本，而不会在sql server上运行

总的来说，数据库独立数据迁移的问题在企业Java中仍未解决？

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

这么说来，我想你可能对飞行路线和液体饮料有错误的想法。正如我之前所说的，与其说它们是数据库版本控制工具，不如说它们不是真正的“迁移工具”。通过排序的特定sql迁移脚本列表，我可以保证数据库在任何版本下的状态。我不确定我是否会使用这些工具将基于SQL Server的旧应用程序“迁移”到基于PostGres的应用程序中。