数据库独立数据迁移

Question

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

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

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

建筑

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

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

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

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

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

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

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

假设和研究

StackOverflow 1 2 3 4 5 6 7：回答州使用Hibernate的内置功能。但是，文档声明这不是production ready。此外，AFAICT，所有答案都只关注架构迁移。

Liquibase：使用自定义DSL（在XML / JSON / YAML / etc中）以允许仅与数据库无关的架构迁移。

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

flyway：原则上与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 / Flyway与JOOQ结合使用，我也看不到如何执行数据迁移，因为Liquibase / Flyway将数据库迁移到位。旧数据库被破坏，并有机会将旧数据转换为新模式。

感谢您的关注！

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，并且我认为你应该使用它的全部内容，那么这并不是什么大不了的事。

所有这一切，我想你可能对flyway和liquibase有错误的想法。就像我之前说过的那样，他们并不是真正的移植工具。它们是数据库版本控制工具。通过订购的特定sql迁移脚本列表，我可以保证任何版本的数据库状态。我不确定这些是我用来“迁移”的工具。基于SQL Server的遗留应用程序到基于PostGres的应用程序中。