マルチテナントシステムで、各テナントデータを互いに分離するための正しい方法は何ですか？
私は初めてのAzure開発者であり、シングルテナントのクラウドシステムを引き継いでおり、システムをマルチテナントに変換する役割を担っています。各テナントのSQLサーバーデータを分離する正しい方法は何ですか？
そのデータ収集と報告システム。各テナントは、データに関する独自のカスタムレポートを作成して実行する必要があります。では、マルチテナントでは、テナントがお互いのデータを見ることをどのように防ぐのですか？
Windows Azureなどのクラウドコンピューティング固有のアーキテクチャを使用しても、プログラミングで何かを行う「正しい」方法はありません。
MSDNドキュメントの大まかな検索 は、Azureが実際にクライアントのデータを分離するのに役立ついくつかの便利な機能を備えていることを示しています。各クライアントに独自のSQLサーバーインスタンスを与えるか、直接パーティション化するか、いくつかの組み込み機能を利用してパーティション化する共通インスタンスを代わりに使用できるように見えます。
これらのソリューションにはそれぞれ長所と短所があり、自分で評価する必要があります。選択に関するいくつかの概念的なガイダンス：
- クライアントごとに個別のインスタンスを使用する場合、クライアントのデータの分離が組み込まれますが、複数のクライアントからのデータを検査する機能が一部低下します。マイクロソフトは、追加のオーバーヘッドに対して追加料金を請求する場合もあります。
- 同じインスタンスを使用しているが、単一のデータベースで手動でデータを分割する場合は、さまざまなキーとインデックスを自分で管理および調整する必要があります。明らかに、大規模なクライアントの50,000,000レコードが、小規模なクライアントの500レコードのクエリの速度を低下させることは望ましくありません。
- 単一のサーバーインスタンスで各クライアントに個別のスキーマまたはデータベースを提供すると、クエリ管理が容易になりますが、サーバーロックについて心配する必要がある場合があります。 （プラス面として、seperate-db-per-clientを使用すると、移行が容易になります。）
- Microsoftのbulit-inパーティションツールを使用している場合、それらのツールは、ユーザーが実行したいことを正確に実行できる可能性があります。または、実装の70％の方法で、ツールがカバーしていないニーズを発見し、作業の多くを放棄する必要があるかもしれません。 （他人のツールチェーンを使用する場合は、調査と適切なモデルが重要です。）
「シングルインスタンスからマルチインスタンスにデータをどのように移動するのか」という質問については、新しいアーキテクチャを構築してから古いデータをインポートすることが主な問題になると思います。とにかく、将来のクライアントのためにそれを行う方法を知りたいでしょう。
多くの人は、顧客ごとに1つのデータベースを持つという考えにすぐに飛びつきます。ほとんどの場合、それは不要であり、データベース構造の同期を維持するという追加の問題を引き起こします。もちろん、それらに異なるデータベース構造（異なるテーブルと列の定義）を持たせたい場合、またはデータベースへの直接アクセスを許可したい場合は、これが目的です。
マルチテナントシステムの最も一般的な方法は、組織または顧客IDを介してデータベース内のデータを論理的に分離することです。データが多かれ少なかれ正規化されていれば、データベースクエリを変更する必要がある場合でも、データベースクエリはそれほど複雑にならないはずです。