別々のデータベース間の関係は悪い習慣ですか？

複数のデータベースを持つクライアントを使用しています。レベルデータベース（アプリケーション固有のDB）masterからの関係を持ついくつかのレベルデータベースがありますinstance。fromからinstancetoへの関係masterは、のテーブルへの主キーを表す整数値ですmaster。のビューとストアドプロシージャは、これらのストアドキーを介してinstancesデータをロードするように設定masterされています。

明らかに、実際の参照整合性はありませんが、それは悪い習慣なのinstanceでしょうか、それともデータベースの読み取り専用テーブルにデータを常駐させるべきなのでしょうか。

唯一の問題は、これらの関係を強制するための本当に便利な方法がないことです。トリガーのボートロードを使用するか、マスターテーブルを各インスタンスデータベースに格納し、ビューを使用して、それらすべてをメタデータとしてマスターに公開することができます。

最大のマイナス面は、データを正確に同期化することと関係があると私は思います。少なくとも3つのシナリオが頭上にあります（これらはすべて、トリガーを使用しても問題になる可能性があります）。

• 不適切に調整されたクロスデータベーストランザクション -たとえば、あるトランザクションが新しい行をマスターに追加し、IDを別のトランザクションに引き渡した後、最初のトランザクションがロールバックします。
• 単一のデータベース障害からの回復 -データベースがクラッシュした場合、他のデータベースでの他の正常なトランザクションが完了する前の時点に復元する必要があります。これは、インスタンスデータベースを以前の時間に戻す必要がある場合、マスターが予期する行が欠落していることを意味します。マスターが元に戻す必要がある場合は、すべてのインスタンスデータベースにマスターに存在しない値が含まれる可能性があります。
• 一般的にバックアップの一貫性 -災害復旧が必要な場合、すべての完全バックアップとログバックアップをトランザクションのある時点まで一貫性を保つのに苦労します。ファイルシステムのスナップショットはこれには役立ちません。また、可用性グループでさえ、単一の可用性グループ内のデータベースのデータベース間のトランザクションの一貫性は保証されません。災害が発生し、データベースを新しいシステムに復元する必要がある場合、トランザクションの一貫性を確保する方法はありません。

そうは言っても、私はこれまでも、そしてこれからも、テナントを独自のデータベースに分離するファンであり、中央データベースに関連するリスクがあることを認めていますが、それは必要です。

（余談ですが、マスター/インスタンス以外のデータベースの名前を使用する必要masterがあります。SQLServerでは間違いなく明確な意味があり、上記の自分の単語を読んでも曖昧になる可能性があります。前と同じですinstance。以前の人生ではマルチを実行しました-テナントシステムと呼ばれ、中央データベースControlとテナントデータベースを呼び出しましたTenants。

マイクロサービスのようなアーキテクチャーを使用している場合、それぞれが独自のデータストアを持つ複数の自律サービス間でデータを関連付けることができることは、ほとんど必須です。各サービスによって、従来は単一のデータベーストランザクションで実行されていたビジネスプロセスが、実行時間が長くなる可能性があることが理解されます。