私の SOA には、ユーザー サービスと製品サービスの 2 つのサービスがあります。ユーザーと製品の両方に、国と産業の 2 つのオブジェクトで「タグ付け」できます。これは、両方のサービスに結合テーブルがあり、将来のサービスでもそれが必要になることを意味します。国や業界のデータベースは標準化して、できれば一元管理してほしい。私が考えることができるいくつかのオプションがあります：
良いオプションがありませんか？これらの 2 つまたは他の提案のうち、どれを採用しますか?なぜですか?
UserテーブルとProductテーブルの参照整合性について心配しすぎる場合は、これらのテーブルの読み取り専用コピーを複数のデータベースに保持し、FKを確立します。次に、すべてのコピーを最新の状態に保つための単一のサービスを作成します。
それ以外の場合は、オプション1で説明したハブスポークソリューションがその役割を果たします。ただし、優れたデータ品質を確立するには、ユーザーテーブルと製品テーブルへのデータ入力をプログラムで制御する必要があります。
Replicationを調べることをお勧めします。あなたの説明からすると、スナップショット レプリケーションが最も適しているように思えます。共通テーブルを維持するデータベースが 1 つあり (専用アプリやダイレクト SQL などを使用)、サービス データベースがサブスクライバーになります。SQL Server は、サーバー間でデータをコピーします。
その場合でも、共通テーブルへの外部キーを持つことができます (これらは各サービス データベースに表示されるため)。
これは実質的にオプション2ですが、「マスターテーブルとスレーブテーブルを同期する方法」ビットが記入されています.
すべてのテーブルを含む 1 つのデータベースを使用し、両方のサービスからデータベースへの接続を開き、クリーンなトランザクションを記述して、ACID プロパティに (可能性が低い) 問題を処理させますか?
シンプル、効率的、簡単に実行できます。
このソリューションの機能を妨げる要件はありますか?
現在、基本的に単純さとパフォーマンスを比較しています（参照整合性は問題ではないと述べたため）。オプション 1 では、すべてが一元的に配置され、管理されます。データをプルするために追加のネットワーク ホップが必要になりますが、古いデータや、独自の問題が発生する可能性のある複数のデータベースの管理について心配する必要はありません。メインサーバーが機能している場合は、誰にとっても機能します。オプション 2 では、データをローカルに保存するとパフォーマンスが向上しますが、システムの長期的なメンテナンスが複雑になり、データの不整合の問題が発生する可能性があります (ただし、データが国や業界であることを考えると、データは頻繁には変更されないため、必要はないはずです)。頻繁に更新されます）。
私の推奨事項は、より単純なソリューション (オプション 1) を構築し、必要に応じてパフォーマンスを調整することです (オプション 2 または他のソリューションを使用することもできます)。ローカル データベースを追加する前に、サーバー間のレイテンシを調べてパフォーマンスを調整すると、インデックスまたは統計で問題を解決できる場合があります。
レプリケーションとデータ キャッシングは、興味深い話題の 1 つですが、正しい選択はめったにありません。データベースは共有データを扱うように設計されており、ほとんどのデータベースはそれが得意です。次のような特定の要件に対応する場合にのみ、データの複数のコピーを保持する必要があります。
特別な要件がない場合は、Kdansky に耳を傾けてください。複雑にしないでおく。データ整合性モニターを作成するのではなく、開発時間の多くをユーザーに機能を提供することに費やしてください。