1

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 ?

4

3 に答える 3

2

上記のヒッチハイクガイドへの素敵な参照。

私の2セント。仕事に適したツールを使用することを検討する必要があります。この問題を解決するにはカスタム コードを作成する必要がありますが、ソースからターゲットへのマッピング、属性から属性へのカスタム変換を行い、市場投入までの時間を短縮できる可能性が高いツールが多数あります。

ETL ツールに注目してください。私はオープン ソース コミュニティで利用できるツールに慣れていませんが、その方向に傾くと、いくつかのツールを見つけることができると確信しています。その他のツールとしては、Informatica、Data Integrator、SQL Server Integration Services があります。空間データを扱う場合は、Alteryx という別のツールがあります。

ティム

于 2010-03-04T22:41:40.867 に答える
1

ORM でこれを行うと、巧妙に作成された SQL スクリプトよりも桁違いに遅くなる可能性があります。DBのサイズによって異なります。

編集

決定は、SQL に関する専門知識ではなく、2 つのスキーマ間の違いの量に依存する必要があることを付け加えておきます。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 に答える