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

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

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

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

ビジネス内の主な懸念は以上です。

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

これらの懸念にどのように対処し、どの解決策が望ましいか、そしてその理由をどのように確認しますか？（同様の質問への回答も編集しています）

以下は、他のソースからの研究のハイライトです（元は質問の改訂2から）。

• アプリケーションごとに1つのデータベースを使用するか、複数のアプリケーション間で単一のデータベースを共有する必要がありますか

• マルチテナンシーのサポート

• MSDN マルチテナントデータアーキテクチャ

• SO 共有テーブル構造を持つマルチテナントデータベースを作成する方法は？

• CloudExpo SaaS- マルチテナントデータベース設計オプション

• MSDNブログマルチテナントデータベースモデルへの移行がSQL Azureフェデレーションで簡単に

• SQL Server Central Oneデータベースに問い合わせますか、それとも複数ですか？

• SQL Server Central 異なるデータベース/アプリケーションのテーブルを1つのデータベースに混合

• Ayende @ Rahienブログマルチテナンシー-物理データモデル

• コードプロジェクトマルチテナントデータベースアーキテクチャ

• ソフトウェアマルチテナントデータベース設計のジョエル

• SO 1つのデータベースを使用する複数のアプリケーションですか？

• SO 単一または複数のデータベース

• コードラント-マルチテナンシーパート1、戦略とパート2、コンポーネントとコンテキスト

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

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

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

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

ですから、忘れないでください、巨大なデータベースよりも数種類のデータベースをスケールアウトするほうが何倍も安く、何倍も簡単です）

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