マルチテナントデータベースの設計

Question

私の上司は現在、マルチテナント対応のERP/CRMシステムのデータベース設計に取り組んでおり、SQL Serverバックエンドを備えています。

設計の重要なポイント：

サーバーインスタンスは、「共有」データベース（一意のモデル）と、会社ごとに1つのデータベース（同じモデル）をホストします。
「共有」データベースには、他の会社のデータベースによって参照される連絡先、ユーザーなどのテーブルがあります。
「共有」データベースには、データを安全に削除できるかどうかを確認するトリガーがあります（いずれかの会社で使用されている場合、DELETE操作は失敗する必要があります）
セキュリティ上の理由から、企業が共有可能な情報を使用してはならない場合、実際にはその企業のみが使用する独自の「共有」データベースを備えた独自のサーバーインスタンスに設定する必要があります。

そして、これがシステムの実装例です。

サーバーインスタンス1：

共有DB
ACME
WayneEnterprises
KwikEMart

サーバーインスタンス2：

共有DB
傘

私の上司は、次の信じられている利点についてこの設計を支持しています。

会社ごとに1つのdbがあるため、KwikEMartのような小さな会社は、大きな会社の重みに悩まされることはありません。
ユーザーアクセスは、「会社ごと」の戦略で定義できます。このようにして、ApuにはKwikEMartのInvoicesテーブルを読み取る権限を付与できますが、ACMEの権限は付与できません。

私はこれらの利点を理解していますが、整合性のトレードオフは私には圧倒されるようです。

まず、企業のdbと共有のdbの間には、整合性のカットオフが明らかに存在します。 dbの境界を越えて外部キーを作成することは不可能です。

次に、ジョーカーがWayneEnterprisesデータベースをめちゃくちゃにして、バットマンが1日前のバックアップを復元しなければならない場合はどうなるでしょうか。その同じ日にACMEが、古いWayneEnterprisesデータベースでまだ使用されていた共有Gothamアドレスを削除することを決定した場合、そのアドレスを使用したすべてのドキュメントはそれを表示できなくなります。もちろん、復元可能なまったく同じ時間からの共有データベースバックアップがない限り。しかし、それがあったとしても、ACMEとKwikEMartの両方にさらに多くの問題を引き起こす可能性があります。

そして、それは私の心に浮かんだ2つの問題にすぎません。おそらく他にもあるでしょう。

だから私の質問はここにあります：これで正しい方向に進んでいますか？また、この種のシステムは通常どのように構築されていますか？

どんなガイダンスでも大歓迎です。

RubberChickenLeader · Accepted Answer

私がDBAおよび開発者として取り組んだマルチテナントシステムでは、クライアントごとに1つのデータベースを使用しました。そのデータベースは完全に自己完結型であり、米国の州のようなものすら、共有データベースに依存していませんでした。

新しいクライアントを簡単に立ち上げるために、Statesなどのすべてのものが事前に入力されたモデルデータベースが作成されました。

アドレスやその他の共通データを共有データベースに保存しなかった理由は、データベースを複数の異なるサーバー間で移動して、サーバー間の負荷を正規化できるようになったためです。クライアントのアップグレードのためにデータベースがより高いSLAを必要とする場合は、バックアップを取り、適切なサーバーにクライアントデータベースを復元するだけで、「StarkIndustriesのアドレス」が存在するかどうかを心配する必要はありません。新しいサーバー上。

明らかな質問は、クライアントAが顧客の電話番号または住所を更新するとどうなるかということです。クライアントBはその変更を確認する必要がありますか？すべてが個別のデータベースに格納されている場合、データが「重複」することになりますか？

「StarkIndustries」がクライアントAにクライアントBとは異なる電話番号を使用させたい場合はどうなりますか？次に、それを示してクライアントデータベースに異なる番号を保存するか、クライアントAとクライアントBを異なるインスタンスに移動する方法が必要になります。共有データベースを調べると、データを異なる方法で使用したいさまざまなクライアントのこの問題の追加のインスタンスが見つかると確信しています。

共通テーブルの更新では、各データベースをループするスクリプトを書くのはかなり簡単です。sys.databases上のカーソルと一部の動的SQLがその部分を処理します。

全体として、共有データベースを使用すると、クライアントがさまざまなデータを使用するさまざまな方法を検討し始めると、正規化の観点から見栄えがよくなるかもしれませんが、共有データベースはもう意味がありません。クライアントごとに別個のデータベースのルートを使用する場合は、共有データを使用せずに、完全に分離して完全に分離します。