3

シナリオがあります。私のアプリケーションは、複数のクライアントに対応するSAASベースのアプリです。クライアントへのデータの整合性は非常に重要です。

私のテーブルを保持する方が良いですか

  1. クライアント固有または
  2. リレーショナルテーブル

例：フィールドMapField1、MapField2を持つマッピングテーブルがあります。クライアントごとにこの種のデータが必要です。

MappingData_のようなテーブルが必要ですか

またはClientIdにマッピングされた単一のテーブル

フィールドを含むMappingDataMapField1、MapField2、ClientId

4

2 に答える 2

1

顧客ごと に個別のデータベースを用意します。(単一の SQL Server インスタンス内の複数のデータベース。)

これにより、単一のスキーマで一度設計することができます。

  • テストと開発を損なう動的に名前が付けられたテーブルはありません
  • アップグレードとメンテナンスは、1 つの DB で設計およびテストしてから、すべての DB にロールアウトできます。
  • 1 人の顧客のデータを非常に簡単にバックアップ、復元、削除できます
  • 1 つの DB で発見/悪用されたバグは、他の DB の整合性を構成しません。
  • データ アクセス (読み取りと書き込み) は、SQL ログインを使用して管理できます (車輪を再発明する必要はありません)。

グローバルに共有されたデータが必要な場合、それは別のデータベースに移動し、さまざまな SQL ログインに対する独自の権限セットを使用します。


すべてのユーザーを含む単一のデータベースを使用することは、私の次善の選択です。まだ単一のスキーマがあります。ただし、顧客のデータを分割することはできません。アクセス権と許可を自分で管理する必要があり、その他の追加の設計およびテスト作業のホスト全体を管理する必要があります。


追加の顧客のために新しいテーブルを動的に作成することには決して近づきません。新しいテーブル名は、すべてのクエリを新しいテーブル名で更新する必要があることを意味し、他の多くのメンテナンスの頭痛の種です。

私は、アプリケーション/サービスを通常どおり使用しているときにテーブルを動的に作成したい場合、設計が不適切であるという意見がほとんどです。

于 2012-11-17T10:51:15.430 に答える
0

SOには、あなたが説明しているもののタグがあります：「マルチテナント」。

マルチテナント データベース アプリケーションをサポートするためのアーキテクチャをスペクトルとして視覚化します。スペクトルの 1 つの極端な例は、「共有なし」です。これは、各テナントが独自のデータベースを持っていることを意味します。スペクトルの対極にあるのは「すべてを共有」です。これは、テナントがテーブルを共有し、各テーブルの各行が 1 つのテナントに属していることを意味します。(各行にはテナント ID が含まれます。)

用語が重複しているようですので、よく読んでください。あるライターが共有スキーマで意味することは、別のライターが共有すべてで意味するものと同じかもしれません。

これも私が書いた SO answerでは、コスト、データの分離と保護、メンテナンス、災害復旧に関する違いとトレードオフについて説明しています。また、かなり優れた紹介記事へのリンクもあります。

于 2012-11-17T15:05:41.177 に答える