あるデータベースのマスター テーブルのデータを同期して、他のデータベース (多くの場合、他のサーバー) のテーブルをクローンする必要が頻繁に生じます。たとえば、バックエンド システムが在庫データを管理し、その在庫データを最終的に Web サイト アプリケーションの一部である 1 つ以上のデータベースにプッシュする必要がある場合を考えてみましょう。
バックエンド システムのソース データは、多数のテーブルと外部キー制約を使用して大幅に正規化されています。これは、適切に設計された OLTP RDBMS システムです。問題のテーブルの多くには、数百万行が含まれています。このデータを他のデータベースに定期的にプッシュする必要があります。可能な限り頻繁に。遅延は許容できます。何よりも、バックエンド データベースとリモート データベースの両方のアップタイムを最大化することが不可欠です。
私は SQL Server を使用しており、変更の追跡、行バージョン、トリガーなどに精通しています。Microsoft は、これらのシナリオに対してレプリケーション、SyncFx、および SSIS を強く推奨していることを知っています。ただし、ベンダーのホワイトペーパーと概要で推奨されるテクノロジと、ソリューションの実際の実装、展開、および保守との間にはかなりの違いがあります。SQL Server の世界では、レプリケーションはターンキー ソリューションと見なされることがよくありますが、私は別のソリューションを模索しています。(レプリケーションは管理が難しく、スキーマの変更が難しくなり、再初期化が必要になった場合に重要なシステムに大きなダウンタイムが発生するのではないかという懸念があります。)
たくさんの落とし穴があります。多数のテーブル間の複雑な外部キー関係のため、キャプチャを実行する順序や更新を適用する順序を決定することは簡単ではありません。一意のインデックスが原因で、一度に行単位の更新が機能しないような方法で 2 つの行がインターロックされる場合があります (最終更新の前に各行に対して中間更新を実行する必要があります)。多くの場合、一意のインデックスは通常のインデックスに変更され、外部キーは無効にされる可能性があるため、これらは必ずしもショーストッパーではありません (ただし、外部キーを無効にすることは非常に望ましくありません)。多くの場合、SQL 2008 の変更追跡と SSIS または SyncFx を "そのまま" 使用するという話を耳にします。これらの種類の答えは、実際の困難を正当化するものではありません。(そしてもちろん、クライアントは、データのコピーがいかに難しいかについて頭を悩ませています。
この問題は、最終的には非常に一般的なものです。多くの行を持つ、関連性の高い多くのデータベース テーブルの一方向の同期を実行します。データベースに携わるほぼ全員が、この種の問題に対処する必要があります。ホワイトペーパーは一般的であり、実際の専門知識を見つけるのは困難です。これが難しい問題になる可能性があることはわかっていますが、仕事を終わらせる必要があります。あなたにとって何がうまくいったか（そして何を避けるべきか）について聞いてみましょう。Microsoft 製品または他のベンダーの製品に関する経験を教えてください。ただし、関連性の高い多数のテーブルと行を使用してソリューションを実際にテストしたことがない場合は、回答を控えてください。これは理論的なものではなく、実用的なものにしましょう。