sql-server - クロスデータベースの外部キー参照の欠如に関する SQL 設計

Question

良くも悪くも、すべてが共通の管理データベースを参照する複数のデータベースに依存するソリューションがあります。データベースはモジュールの一部として出荷されますが、すべてのモジュールがインストールに必要なわけではありません (おそらく、最初に複数のデータベースがある理由です)。ただし、管理データベースは必要です...そのため、常に存在します。

混乱に参照整合性と秩序をもたらしたいと思っていますが、SQL サーバーがクロスデータベースの外部キーを実行できないことが妨げになっています。データベースには多くのチャーンはありませんが、技術者以外のユーザーによって情報が挿入/更新されます。

私が見たときの私の選択肢は次のとおりです。

a）トリガーを使用して疑似外部キーを課す（OKですが、少し手間がかかります）

b）トリガーを使用して、管理者から他のデータベースに複製します（災害の明確なレシピ）

c）コード/ DALに疑似外部キーを課す（ORMではうまく機能しない）

d) DB レベルで心配する必要はありません。優れた UI デザインを使用して、誰も愚かなことをしないようにし、アクセスを制限し、SQL への直接アクセスを制限します。

率直に言って、私は「D」に行きたいと思っていますが、私よりも賢い意見を求めると思いました...

score 4 · Accepted Answer

私たちはまったく同じ問題を抱えており、率直に言って、それはひどいものです。私たちが効果的であると判断した唯一の解決策は、オプション D と、ビジネスレイヤーを使用して物事を同期させようとすることでした (トランザクションに含めるなど)。

score 4 · Accepted Answer

各モジュールが管理データベースとリンクするように設定されていると仮定すると、各モジュールデータベース内の管理テーブルのビューを設定することで、物事を単純化できる場合があります。

score 3 · Accepted Answer

当社の製品にはそのようなモジュール性がありますが、インストール中にデータベース要件が統合されます。たとえば、管理パッケージと製品Aは、2つのモジュールをデータベースXにインストールするクライアントによる最初の購入である場合があります。後で製品Bを購入する場合、データベースコンポーネントはデータベースXのすぐ上に階層化され、必要に応じてDRIが追加されます。

設計の観点から個別のデータベースの必要性を私が見た唯一のケースは、ビジネスユニット（企業など）の間にハードラインを描いているときです。その時点で、問題は実際には一種のパーティショニングです。Great Plains Dynamicsは、単一の管理データベースと複数の企業データベースがある場合にこれを行います。ただし、特定の企業のGPの各モジュールは、その単一のデータベースに存在します。

もちろん、別々のデータベースで立ち往生している場合は、Dが最良の選択肢であることに同意します。

score 1 · Accepted Answer

データベースの実装によっては、多くの場合、別のデータベース（AdminDB）のテーブルをリンクして、さまざまなモジュールデータベースに表示させることができます。

Microsoft Accessでは、右クリックしてODBCデータソースを選択することでテーブルをリンクできます。Oracleでは、これをデータベースリンクと呼びます。SQLServerには、単一のテーブルにカスタムレプリケーションを実装する以外に、この実装の何らかの形式があると確信しています。

外部管理テーブルをモジュールデータベースにリンクすると（またはその逆）、テーブルが同じスキーマ内にあるかのように制約を定義できるようになります。

2番目のオプションはさらに簡単かもしれません。すべてのモジュールと管理データベースに同じスキーマを使用した場合はどうなりますか？adminデータベースが存在することがわかっているので、そのスキーマに対してテーブル作成スクリプトを実行するだけです。テーブル/ビュー/ストアドプロシージャの名前の競合がない限り、すべてのモジュールのdbloginを一致するように変更するだけですべて機能するはずです。

score 1 · Accepted Answer

サービス指向アーキテクチャーを実装する必要があります。システム内のさまざまなサービスがデータベーススキーマで実行されている場合。次に、アプリケーションを任意のデータベースから独立して実行できるようにしますが、サービスに対して実行させます。

score 1 · Accepted Answer

すべての変更を中央のサービスに集中させて不整合を生じさせないようにするために、アーキテクチャ的にさまざまな方法でこれに対処できます。障害点は、あなたが持っている他の要件に違反する可能性があります)、データベースエンジン自体に依存して、FK 制約でできるように保証を適用することはできません。

異なるシステムがまだ完全に統合されていなかったり、セキュリティ上の懸念から別の管理者が必要だったりするために同期が取れなくなる可能性がある部門間のデータベースの状況で、私はしばしばこれに対処しなければなりませんでした。

このような場合、私は通常、1 時間ごとに生成される例外レポートに頼っています。例外レポートは、物事の状態をチェックし、問題がある場合にのみ報告します。SQL Server エージェントジョブには、強力なスケジューリング機能があります。私は常にログテーブルと SQLAnswersMail を使用して、さまざまなシステム管理者に素敵な小さな HTML メール (メール内の URL リンクから管理ページに移動して問題を修正することもできます) を生成しましたが、この猫の皮を剥ぐ方法はたくさんあります。

score 1 · Accepted Answer

アプリケーションの重要度に依存すると思います。その管理データベースがダウンした場合でも、制限付きの方法で操作を続行しますか? 管理者がダウンしている場合は、アプリ全体をすぐに停止する必要があります。これまでに述べたことはすべて問題ありません。

「管理データベースがなくても実行できる作業はたくさんあります。」では、一方向のレプリケーションが非常に風変わりであり、災害の明らかなレシピであるとなぜ信じているのでしょうか?

テーブルのコピーを作成することは、ロケット科学ではありません。実際、家の鍵を複製するのと同じくらい簡単です。マスターのあらゆる山と谷が、ブランクを形作るカッティングホイールに伝達されます。マルチマスターレプリケーションにはいくつかの魔法があります。リモートデータベースで、管理データから取得したデータへの変更を許可し始めると、深刻な設計上の考慮事項が開かれます。

これが正しい方法だと言っているのではありません。最初に私の最初の質問に答えてください。その後、運用を継続したい場合は... レプリケーションの実行可能性を軽視しないでください。

score 0 · Accepted Answer

面白いのは、データベースの小さなMS Accessコピーを作成し、AccessでRIを適用してからアップサイズできることです。また、Microsoft Accessでは、トリガーまたはDRIのどちらを使用するかを選択できます。 MicrosoftAccessがトリガーのコア部分を作成してくれることは間違いありません。

このトピックについて話している間、私はMS Accessが嫌いです。しかしAccessの優れている点の1つは、QUERY（sql select、別名view）に対してRIを適用できることです。MSSQLServerにその同じ機能。

score 0 · Accepted Answer

SQL Server には Oracle の具体化されたビューのような機能があるのだろうか? これはビューのようなクエリで定義するオブジェクトですが、クエリの結果はテーブルとして保存されます。その後、自動的にリフレッシュするためのさまざまなメカニズムがあります。

そのような機能がある場合は、各サテライトデータベースのコアテーブルのマテリアライズドビューを作成することをお勧めします。次に、外部キーでそれを参照できます。主な問題は、ニーズに十分な頻度で更新できるかどうかです。

sql-server - クロスデータベースの外部キー参照の欠如に関する SQL 設計

9 に答える 9

Related

Reference