1

我需要同步两个数据库。这些数据库存储相同的语义对象，但在两个数据库中物理上不同。

我计划使用 DTO 模式来统一对象表示：

DB ----> DTO ----> MAPPING (Getters / Setters) ----> DTO ----> DB

我认为这比在每一侧使用 SQL Query 进行物理同步更好，我使用 hibernate 添加抽象并同步对象。

你觉得，这是个好主意吗？

4

3 回答 3

2

上面对 Hitchhiker's Guide 的很好参考。

我的两分钱。您需要考虑使用正确的工具来完成这项工作。虽然编写自定义代码来解决这个问题很有吸引力，但已经有许多工具可以为您做到这一点，将源映射到目标，进行从属性到属性的自定义转换，并且很可能会以更快的上市时间交付。

看看 ETL 工具。我不熟悉开源社区中可用的工具，但如果你倾向于那个方向，我相信你会找到一些。您可能会查看其他工具：Informatica、Data Integrator、SQL Server Integration Services，如果您正在处理空间数据，还有另一个称为 Alteryx。

蒂姆

于 2010-03-04T22:41:40.867 回答
1

使用 ORM 执行此操作可能比精心设计的 SQL 脚本慢一个数量级。这取决于数据库的大小。

编辑

我要补充一点，该决定应取决于两种模式之间的差异量，而不是您对 SQL 的专业知识。SQL 是如此普遍，以至于开发人员应该能够以简洁的方式编写简单的脚本。

SQL还有一个优点，就是大家都知道怎么运行脚本，但不是每个人都知道怎么运行你的自定义工具（这是我在实践中遇到的问题，如果迁移实际上是由其他人操作的）。

  1. 对于仅略有不同的模式（例如名称或列值的简单转换），我会选择 SQL 脚本。这可能更紧凑，更易于使用和交流。

  2. 对于具有重大差异的模式，数据组织在不同的表中或复杂的逻辑以将一些值从一个模式映射到另一个模式，那么专用工具可能是有意义的。编写工具的最初努力可能更重要，但一旦创建它就可以成为资产。

您还应该考虑非功能方面，例如异常处理、错误记录、在较小的事务中拆分工作（因为数据太多）等。

  1. 在这种情况下，SQL 脚本确实会变得“乱七八糟”。如果您有这样的限制，SQL 将需要高级技能并且往往难以使用和维护。

  2. 自定义工具可以演变成一个迷你 ETL，能够将工作分块为小事务，很好地管理和记录错误等。这是更多的工作，并且可以导致成为一个专门的项目。

决定权在你。

于 2010-01-14T16:00:37.793 回答
1

我以前做过，我认为这是在 2 个 DB 之间进行映射的一种非常可靠且直接的方式。唯一的缺点是每当数据库发生变化时，我都必须更新映射逻辑，但这通常很简单。

于 2010-01-14T16:00:47.227 回答