web-dev-qa-db-ja.com

マルチテナンシー-単一データベースと複数データベース

私たちは、いくつかのクライアントを抱えていますが、そのシステムはいくつかの機能を共有していますが、かなりの多様性も持っています。クライアントの数は増え続けています-常に健全なものです！ -そして、ビジネス間の多様性も高まっています。

現在、（Webプロジェクトではなく）単一のASP.Net（Webフォーム）Webサイトがあり、各テナントにサブフォルダーがあり、そのテナントの非標準ページがあります。データベースアクセスとビジネスロジックを扱う別のモデルプロジェクトがあります。

（a）クライアントごとに1つのデータベースを使用し、そのクライアントに関連付けられている機能のみを使用する場合、どちらが望ましいか、そして最も重要な理由は、その理由です。または（b）すべてのクライアントによって共有される単一のデータベース。テーブルのサブセットのみが任意の1つのクライアントによって使用されます。

ビジネス内の主な懸念は終わりました：

  • 複数のアセットのメンテナンス-バックアップ、バージョン管理など
  • 可能な限り再利用を促進する

これらの懸念事項に確実に対処するために、どのソリューションを推奨しますか。また、その理由は何ですか。 （私も同様の質問への回答をまとめています）

database-designprojects-and-solutionsmultitenancy
20
RichardW1001

他の情報源からの研究のハイライトは次のとおりです（元は 質問のリビジョン2 から）：

12
user40980

SQL Serverを使用している場合は、1つのデータベースを使用しますが、スキーマを使用します。すべてのクライアントに一般的なものにはdboを使用し、各クライアントのスキーマを作成して、そのクライアントのユーザーのデフォルトスキーマにします。これで、dboスキーマに一般的なオブジェクト（たとえばgetBudget proc）を作成し、同じ名前のスキーマでクライアント用にカスタマイズしたオブジェクトを作成できます。

10
HLGEM

クライアントのデータベースと機能が異なるため、ある時点でそれらが異なるシステムになることを意味します。この場合、各クライアントのカスタマイズを維持するコストは単一のシステムの利点を上回るため、この場合は個別のシステムをお勧めします。データベースシステム。

単一のデータベースシステムは、異なる顧客間の変更が単なる構成であり、各クライアントの追加機能ではない場合に最適です。

4
Stephen Senkomago Musoke

いくつかの懸念がありません。問題は成長とともに起こります。いつか1つのDBサーバーよりも大きくなると想定できる場合、1つの複雑なデータベースは間違いなく頭痛の種になります。事前にアーキテクチャに投資しない限り。しかし、それはまた高価なステップです）

ですから、巨大なデータベースよりも、いくつかの異なるデータベースをスケールアウトする方が、何倍も安く、何倍も簡単であることを忘れないでください）

3
stim

回答で取り上げられていない領域の1つは、マルチテナントDBアプリケーションを正しく保護することに関する問題です。マルチテナントアプリは、セキュリティの問題を回避するために非常に注意深く設計する必要があります。ほとんどのデータベースとアプリは、完全ではありませんがいくつかの分離を提供します-通常、DBスキーマ全体でデータを直接的または間接的に推論する方法があります。そして、少なくとも、他のテナントへの簡単なサービス拒否攻撃につながる可能性がある、かなりの数の共有リソース（ログやその他のファイル、DBAテーブル、カーソル...）があり、通常はそれ以上です。

1
Egret