Home/ Questions/Q 564103
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T12:43:52+00:00

I need to synchronize two databases. Those databases stores same semantic objects but physically

  • 0

I need to synchronize two databases.
Those databases stores same semantic objects but physically different across two databases.

I plan to use a DTO Pattern to uniformize object representation :

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

I think it’s a better idea than physically synchronize using SQL Query on each side, I use hibernate to add abstraction, and synchronize object.

Do you think, it’s a good idea ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Doing that with an ORM might be slower by order of magnitude than a well-crafted SQL script. It depends on the size of the DB.

    EDIT

    I would add that the decision should depend on the amount of differences between the two schemas, not your expertise with SQL. SQL is so common that developers should be able to write simple script in a clean way.

    SQL has also the advantage that everybody know how to run the script, but not everybody will know how to run you custom tool (this is a problem I encountered in practice if migration is actually operated by somebody else).

    1. For schemas which only slightly differ (e.g. names, or simple transformation of column values), I would go for SQL script. This is probably more compact and straightforward to use and communicate.

    2. For schemas with major differences, with data organized in different tables or complex logic to map some value from one schema to the other, then a dedicated tool may make sense. Chances are the the initial effort to write the tool is more important, but it can be an asset once created.

    You should also consider non-functional aspects, such as exception handling, logging of errors, splitting work in smaller transaction (because there are too many data), etc.

    1. SQL script can indeed become “messy” under such conditions. If you have such constraints, SQL will require advanced skills and tend to be hard to use and maintain.

    2. The custom tool can evolve into a mini-ETL with ability to chunck the work in small transactions, manage and log errors nicely, etc. This is more work, and can result in being a dedicated project.

    The decision is yours.

    • 0