さまざまな構造の情報をどのように保存できますか？
この問題の名前を思い付くのに苦労していますが、以前に解決されたように感じます。私の初心者は、正しい単語をGoogleに入力して必要な結果を得ることを妨げていると思います。この質問が以前に尋ねられた場合は、事前に謝罪します。
とにかく...
データの構造がテナントに依存するマルチテナントWebアプリを設計しています。この場合のテナントは、当社のサービスを利用したい企業であり、ユーザーとは、それらの企業のいずれかで働いている個人のことです。すべてのユーザーがログインする1つのWebサイトがあるように、システムはすべて1か所にあります。入力した電子メールアドレスによっては、割り当てられたテナントは登録時に自動的に決定されます（わからないこれがこれに対処する正しい方法でさえある場合）。
各テナントは、私たちのシステムで働いている人々に関する情報を保存したいと考えています。これらの人々は必ずしもユーザーである必要はありません、そして最も重要なことに、この人々の情報はより一般的かもしれないウェブサイトの他の部分で使用されます。
ここに問題があります：各テナントは人々に関するさまざまな情報を保存したい場合があります。たとえば、テナントAは名前、電子メール、電話、アドレスを保存したいが、テナントBは名前を保存したいとします。メール、人物の写真、お気に入りの食べ物（わかりません）。
SQL Serverを使用してデータを保存しています。私の本能は、テナントごとに異なるテーブルを作成することですが、テナントの数が増えるにつれ、状況が乱雑になると予想しています。 5つのテナントがある場合、個々のテーブルは確実に機能しますが、500のテナントがある場合はどうでしょうか。情報を保存するすべての人のために500テーブルが必要ですか？しかし、それはさらに悪化します。異なる情報は、各テナントの人々だけのものではありません。テナントは、私たちが提供する他のサービスのためにさまざまな情報を保存することを望んでいる場合があります。
このさまざまなデータ構造を何らかの形で一般化することは可能ですか？このようなことを以前に扱った人はいますか？
すべてのテナントで標準的なデータと、テナントごとに異なるデータを分離する必要があります。
さまざまなデータをXMLまたはJSONで保存できます。より大きなテーブルの単一のフィールドとして、または複数のフィールドとして、それはデータの性質に依存します。 SQL Serverには、JSON構造にクエリを実行する機能があり、おそらく（ただし、100％確実ではありません）XMLでもこれを実行できます。
スキーマはXML用に定義できるため、必要に応じて、そのテナントのカスタムスキーマの各テナントのデータを検証することもできます。 JSONのスキーマを定義する方法もあると思います。
そのルートに行きたくない場合は、これも処理できる優れたEntity-Attribute-Valueモデルがあります（ https://en.wikipedia.org/wiki/Entity–attribute–value_model ）
もちろん、システムがユーザーにカスタム属性の操作（新しい属性の追加、既存の属性の変更、削除など）を許可することも確認する必要があります-すべてがJSON/XMLまたはEAVモデルにダンプされるかどうか。
問題は新しいものではなく、これに対する「1つのサイズですべてに対応する」ソリューションはありません。システムを保守可能な状態に保ちたい場合は、さまざまな要件すべての単一の属性についてを分析し、ケースバイケースでそれを設計する方法を決定する必要があります。
すべてのテナントで使用可能な標準属性として（データベースの標準列としてモデル化するのに最適）
または、多くのテナントで使用可能な属性（データベースの標準列としてモデル化することもできますが、それを必要とするテナントのUIにのみ表示されます）。
または@FrustratedWithFormsDesignerによって提案されたEAVアプローチ、または「XMLまたはJSON」アプローチを使用して最適にモデル化されたカスタム属性（これは通常、テナントが自分で新しい属性を自由に追加したい場合、おそらく「perレコード」ベース）
または、@ pfuetzによって提案されているように、属性が「子」テーブルに最も適合する場合（おそらくテナント固有の子テーブルですが、そのような子テーブルをアプリケーションの名前付き機能に関連付けて、どのテナントを決定するかをお勧めします）この機能にアクセスできます）
多くの場合、標準列はEAVアプローチよりもはるかに管理しやすいことに注意してください。それらのビジネスロジックを実装する方が簡単であり、標準SQLクエリがよりシンプルになり、ユーザーインターフェイス設計を列に固有にできるようになり、データベースの移行がより簡単になります。 、彼らははるかに自己文書化されています。したがって、本当に必要な場合にのみ、EAVを使用することはめったになく、注意してお勧めします。
各テナントのテーブルを複製し、各コピーを少し変更すると、間違いなくメンテナンスの問題が発生します。これを10回行うと、コピーされた属性ごとに10回のメンテナンスが必要になります。だから私はそれに対して強くお勧めします。
テナントにデータ構造を「モデル化」する機能を提供します...何らかの方法で。
複数のテナントのデータとワークフローのサンプルリクエストをいくつか取り、すべてに共通する一般的な構造を見つけることをお勧めします。次のような一般的な懸念事項がいくつかあります。
- ユーザー管理
- アクセス制御
- 認証
- ユーザー階層のようないくつかの一般的な機能
したがって、一般的なもののベーステーブルから開始する場合があります。次に、テナントがこれらのエンティティにフィールドを動的な方法（フォーマット、検証、およびすべて）で個別のEAV拡張テーブル（各ベーステーブルに1つ）に追加できるようにします。基本的に、一部の一般的なコンテンツ管理システムが「カスタムフィールド」と呼ぶものと同様です。