我需要同步两个数据库。 这些数据库存储相同的语义对象,但在两个数据库中存在物理上的不同。
我打算使用DTO模式来统一对象表示:
DB ----> DTO ---->映射(Getters / Setters)----> DTO ----> DB
我认为这比使用SQL Query在每一侧进行物理同步更好,我使用hibernate来添加抽象,并同步对象。
你认为,这是一个好主意吗?
答案 0 :(得分:2)
Hitchhiker's Guide上面有很好的参考。
我的两分钱。您需要考虑使用正确的工具来完成工作。虽然编写自定义代码来解决这个问题很有吸引力,但是有许多工具已经为你做了这些,将源映射到目标,从属性到属性进行自定义转换,并且很可能提供更快的上市时间。
查看ETL工具。我不熟悉开源社区中可用的工具,但如果你倾向于那个方向,我相信你会找到一些。您可能会看到的其他工具有:Informatica,Data Integrator,SQL Server Integration Services,如果您正在处理空间数据,还有另一个名为Alteryx的工具。
添
答案 1 :(得分:1)
使用ORM执行此操作可能比精心设计的SQL脚本慢一个数量级。这取决于数据库的大小。
修改强>
我想补充一点,决定应该取决于两种模式之间的差异,而不是你对SQL的专业知识。 SQL很常见,开发人员应该能够以干净的方式编写简单的脚本。
SQL的优势还在于每个人都知道如何运行脚本,但并不是每个人都知道如何运行自定义工具(如果迁移实际上由其他人操作,这是我在实践中遇到的问题)。
对于只有略有不同的模式(例如名称或列值的简单转换),我会选择SQL脚本。这可能更紧凑,更易于使用和沟通。
对于主要差异的模式,将数据组织在不同的表或复杂逻辑中以将某个值从一个模式映射到另一个模式,那么专用工具可能有意义。编写工具的初始努力可能更重要,但一旦创建它就可以成为资产。
您还应该考虑非功能性方面,例如异常处理,错误记录,在较小的事务中拆分工作(因为数据太多)等。
在这种情况下,SQL脚本确实会变得“混乱”。如果您有这样的约束,SQL将需要高级技能,并且往往难以使用和维护。
自定义工具可以演变成一个迷你ETL,能够在小事务中调整工作,很好地管理和记录错误等等。这是更多工作,可以导致成为一个专门的项目。
决定权归你所有。
答案 2 :(得分:1)
之前我已经这样做了,我认为这是一个非常可靠和简单的方法来映射2个数据库。唯一的缺点是,无论何时数据库发生变化,我都必须更新映射逻辑,但这通常很简单。