ただし、もちろん、データが危険にさらされる可能性があることを恐れている企業もあるため、他のソリューションを評価しています。
物理的な隔離だけが十分なセキュリティを提供できるという誤解に顧客が苦しむことがあるため、これは残念なことです。
マルチテナントデータアーキテクチャ というタイトルの興味深いMSDN記事があります。 、確認することをお勧めします。これは、著者が共有アプローチに対する誤解に対処した方法です：
よくある誤解は、物理的な分離だけが適切なレベルのセキュリティを提供できるというものです。実際、共有アプローチを使用して保存されたデータも強力なデータ安全性を提供できますが、より洗練されたデザインパターンを使用する必要があります。
技術的およびビジネス上の考慮事項については、この記事では、特定のアプローチが別のアプローチよりも適切である可能性がある場所について簡単に分析しています。
提供する予定のテナントの数、性質、およびニーズはすべて、データアーキテクチャの決定に無関心に影響します。次の質問のいくつかは、より孤立したアプローチに偏る可能性がありますが、他の質問は、より共有されたアプローチに偏る可能性があります。
何人の入居予定者をターゲットにすると思いますか？権限を持って将来の使用を見積もることができるところはどこにもないかもしれませんが、桁違いに考えてください。何百ものテナント向けのアプリケーションを構築していますか？数千？何万もの？もっと？テナントベースが大きくなると予想されるほど、より共有されたアプローチを検討する可能性が高くなります。
平均的なテナントのデータが占めるストレージスペースはどれくらいになると思いますか？一部またはすべてのテナントが非常に大量のデータを格納すると予想される場合は、これらの個別のデータベースアプローチがおそらく最適です。 （実際、データストレージの要件により、とにかく別のデータベースモデルを採用する必要がある場合があります。そうであれば、後で別のデータベースアプローチに移行するよりも、最初からその方法でアプリケーションを設計する方がはるかに簡単です。）
平均的なテナントがサポートすると予想される同時エンドユーザーの数はいくつですか？数が多いほど、エンドユーザーの要件を満たすためのより適切な、より分離されたアプローチになります。
テナントごとのバックアップや復元機能など、テナントごとの付加価値サービスを提供する予定はありますか？このようなサービスは、より分離されたアプローチによって提供するのが簡単です。
更新： さらに、予想されるテナント数について更新します。
その予想されるテナント数（10k）は、すべてではないにしても、ほとんどのシナリオでマルチデータベースアプローチを除外する必要があります。 10,000個のデータベースインスタンスを維持し、毎日何百もの新しいインスタンスを作成する必要があるという考えに夢中になるとは思いません。
そのパラメータだけから、共有データベースの単一スキーマアプローチが最も適しているように見えます。テナントごとに約50Mbを保存し、テナントごとのアドオンがないという事実により、このアプローチはさらに適切になります。
上記のMSDNの記事では、共有データベースアプローチのセキュリティに関する考慮事項に取り組む3つのセキュリティパターンについて説明しています。
アプリケーションのデータ安全対策に自信がある場合は、クライアントにサービスレベル契約を提供できます。 強力なデータ安全性を保証します。 SLAでは、保証とは別に、データが危険にさらされないようにするために講じる措置についても説明できます。
更新2： どうやらMicrosoftの連中はこのテーマに関して新しい記事を移動/作成しましたが、元のリンクはなくなり、これが新しいリンクになります：マルチテナントSaaSデータベーステナンシーパターン （Kudos to Shai Kerer）