私たちは新しいバージョンのWebアプリケーションを開発しています。 複数のクライアント(500以上)があり、各クライアントは独自のデータを持つ独自のデータベースを持っています:ユーザー、製品...複数対単一データベース
新しいバージョンでは、すべてのクライアントはいくつかのデータを共有します。プラットフォームに入る予定ですが、各クライアントは自分のユーザーにしかアクセスできませんが、各クライアントのユーザーにはすべてのユーザーを集中テーブルに入れたいと考えています。
その他の商品、注文などは、各クライアントに帰属します。
各クライアントには、ドメインにインストールされているウェブアプリのコピーがあります。 私たちのアプリは、SQL Serverを使用してASP MVC Entity Framework Code Firstです。
私たちの質問は次のとおりです。
オプションA:自分のテーブルを含む、クライアントごとに1つのデータベース(製品、受注...)と、ユーザーや他の一般的なデータを格納するための一つの共通のデータベース。
オプションB:すべてが含まれている1つの大きなデータベースで、特定のテーブルにClientIdを追加すると、クライアントはそのデータのみを表示します。
長所と短所:
我々はいくつかのデータベースを持っているオプションAで、我々は、テーブル内の100.000注文を持つことができ、そのデータを取得するのは簡単です。一方、我々はデータベース間の照会と2つのデータコンテキストを扱う必要があります。これは、ほとんどのクエリのユーザーデータを取得するために必要な、データベースとクライアント特有のものと一般的なものの両方へのアクセスを意味するprolemです。
オプションBを使用すると、1つのコンテキストのみを処理するだけで、クエリははるかに簡単になります。このアプローチの主な関心事は、クライアントごとに1年あたり10.000を超えるレコードを持つテーブルがあることです。したがって、10年間で500人のクライアントがいると、50万のレコードを持つテーブルを持つことができ、これがパフォーマンスに影響する可能性があります。
ありがとうございます。私たちは、ゲーム内で1つのより多くの事を持っているので
EDIT
はここのものは、複数のデータベース対単一アボ問題ではない、すべてのクライアントが共通のデータベースにアクセスする必要があります。
EDIT 2
のは、我々はすべて私達の顧客のための単一のデータベースのために行くことに決めたとしましょう。したがって、複数のドメインがあり、それぞれがアプリケーションを実行していますが、それぞれのドメインはデータのみを取得する必要があります。
どうすればこのことができますか?各テーブルにClientIdを追加し、各サイトのweb.configでパラメータ "clientId"を使用してデータをフィルタリングしますか?
あなたは、現在、各クライアントのサイトで敷地内にSQL Serverを使用していますか? 1つの中央データベースでは、ネットワークの待ち時間を考慮する必要があります。このラインに沿って、彼らはすべて地理的に近いですか?セキュリティはあなたにとって大きな懸念になるでしょう。 –
オプションBの懸念を緩和するために、テーブルを分割することができます –
この時点ではすべてのデータベースが同じサーバー上にあります...私たちが考えている唯一のことは、グローバル・プラットフォームの開発 –