ユーザーが任意のコンピューターを介してアクセスできるバックグラウンド
構築。online information systemすべての大学や組織にDBとコードを複製したくありません。サインイン
のようなドメインにアクセスして使用してほしいだけです。
2番目のユーザーの場合も、同じドメインのサインインを押して使用します。しかし、それらのデータは異なります。
シナリオでは、大学に200人の従業員がいて、2番目の大学に150人の従業員がいるとします。Qusetionwww.example.comwww.example.com
大学ごとに個別の従業員テーブルを用意する必要がありますか、それとも大学IDを持つ列を持つ単一のテーブルを用意しても大丈夫ですか？
2番目が最適だと思いますが、20の大学または組織があり、合計で数千人の従業員がいるとします。
最善のアプローチは何ですか？
これと同じことがすべてのテーブルに当てはまりますか？これは単なる例です。
ありがとう
アプローチは、データ、使用法、およびクライアントの要件/制限によって異なります。
duffymoが提案するように、統合モデルを使用します。これは、各組織がより大きな全体の一部であり（つまり、すべての大学が州立大学の理事会の一部である）、クロスクエリアクセスに関するセキュリティ上の懸念が最小限である場合に適切な場合があります2。このアプローチでは、同じスキーマ1と関係が「オープンに」共有されるため、各組織間で最小限の分離が行われます。最初は非常に単純なモデルになりますが、データの別の次元を追加するため、組織固有の値の関係が必要な場合は、非常に複雑になる可能性があります（複合FKとその正しい使用法）。
マルチテナンシーを実装します。これは、リレーション（おそらく、ビューとストアドプロシージャの背後に隠されている）、さまざまなスキーマ、またはその他のデータベース固有のサポートに対する暗黙のフィルターを使用して実現できます。実装によっては、すべてのデータが同じデータベースに存在する場合でも、スキーマまたはリレーションを共有する場合と共有しない場合があります。暗黙的な分離を使用すると、いくつかの複雑なキーまたは関係を非表示/削除できます。マルチテナンシーの分離は、一般的にクロスクエリを困難/不可能にします。
データベースを完全にサイロ化します。各顧客または「組織」には、個別のデータベースがあります。これは、個別のリレーションとスキーマグループを意味します。このアプローチは自動化されたツールを使用すると比較的簡単であることがわかりましたが、複数のデータベースを管理する必要があります。必要に応じて「リンクされたデータベース」を使用できますが、直接のクロスクエリは不可能です。
「単一のDB」ではありませんが、この場合、次の制限がありました。1）組織間でデータを共有/公開することは許可されておらず、2）各組織は独自のローカルデータベースを必要としていました。したがって、私たちの製品はサイロアプローチを使用することになりました。選択したアプローチが顧客の要件を満たしていることを確認してください。
インデックスとクエリが正しく計画されている限り、これらのアプローチのいずれも、「数千」、「数十万」、さらには「数百万」のレコードに問題はありません。ただし、あるものから別のものに切り替えると、想定される多くの制約に違反する可能性があるため、決定は早い段階で行う必要があります。
1この応答では、「スキーマ」を使用して、データベースモデル自体ではなく、データベースオブジェクト（テーブル、ビューなど）のセキュリティグループを参照しています。個別のデータベースを使用する場合でも、実際に使用されるデータベースモデルは、共通/共有にすることができます。
2統合されたアプローチは必ずしも安全ではありませんが、本質的に他の設計の組み込みの分離の一部を持っていません。
UNIVERSITY テーブルと EMPLOYEE テーブルを正規化し、それらの間に 1 対多の関係を持たせます。
特定の大学に関係する人だけがデータを閲覧できるように注意する必要があります。役割ベースのアクセスが重要になります。
これは、マルチテナント アーキテクチャと呼ばれます。あなたはこれを読むべきです：
http://msdn.microsoft.com/en-us/library/aa479086.aspx
スキーマごとのテナントを使用します。これは、異なるスキーマ間で構造をコピーすることを意味しますが、すべての SQL DDL をソース管理に保持する必要があるため、スクリプトを作成するのは非常に簡単です。
すべてを同じテーブルで行うと、テナント間で情報を台無しにしたり、「漏えい」したりするのは簡単です。