カスタムフィールドを持つユーザーデータベースをどのように設計しますか

この質問は、データベースをどのように設計する必要がありますか？それは、より良いソリューションになるものに応じて、リレーショナル/ nosqlデータベースにすることができます

「会社」と「ユーザー」を追跡するデータベースを含むシステムを作成する必要があるという要件があるとします。1人のユーザーは常に1つの会社にのみ属します

• ユーザーは1つの会社にのみ所属できます
• 会社は多くのユーザーを持つことができます

「会社」テーブルの設計は非常に簡単です。会社には次の属性/列があります：（簡単にしましょう）

ID, COMPANY_NAME, CREATED_ON

最初のシナリオ

シンプルでわかりやすい、ユーザーはすべて同じ属性を持っているため、これはリレーショナルスタイルのユーザーテーブルで簡単に実行できます。

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

2番目のシナリオ

さまざまな企業がユーザーのさまざまなプロファイル属性を保存する場合はどうなりますか。各会社には、その会社のすべてのユーザーに適用される定義済みの属性セットがあります。

例えば：

• 会社Aは、LIKE_MOVIE（ブール値）、LIKE_MUSIC（ブール値）を保管したいと考えています。
• 会社Bが保存したい：FAV_CUISINE（文字列）
• 会社Cは、OWN_DOG（ブール値）、DOG_COUNT（整数）を保存したい

アプローチ1

ブルートフォースの方法は、ユーザーに単一のスキーマを持たせ、彼らが会社に属していない場合にnullを持たせることです：

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

多くのNULLと、それらに関係のない列を持つユーザー行（つまり、会社Aに属するすべてのユーザーはFAV_CUISINE、OWN_DOG、DOG_COUNTのNULL値を持つ）になってしまうため、これはやや厄介です

アプローチ2

2番目のアプローチは、「自由形式フィールド」を持つことです。

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

カスタムフィールドとは何なのかわからないため、それ自体は厄介です。データ型は、格納されている値を反映しません（たとえば、int値をVARCHARとして格納します）。

アプローチ3

PostgreSQL JSONフィールドを調べましたが、その場合は次のようになります。

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

この場合、ユーザーに異なるスキーマをどのように適用できますか？会社Aのユーザーは、次のようなスキーマを持ちます。

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

会社Cのユーザーには異なるスキーマがあります：

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

この問題をどのように解決すればよいですか？データベース（会社）の関係に基づいて、単一の "オブジェクト"（ユーザー）にこの柔軟なスキーマを許可するようにデータベースを適切に設計するにはどうすればよいですか？

リレーショナルソリューション？nosqlソリューション？

編集：私は、「CUSTOM_PROFILE」テーブルについても考えました。これは、基本的にユーザー属性を列ではなく行に保存します。

このアプローチには2つの問題があります。

1）列ではなく行としてユーザーごとにデータが増加します-これは、ユーザーの全体像を取得するために、多くの結合を行う必要があり、異なるカスタム属性の「カスタムプロファイル」テーブルへの複数の結合を意味します

2）データが整数またはブールなどであるとわかっている場合でも、データ値は常に汎用としてVARCHARとして格納されます

これを代替案として検討してください。前の2つの例では、アプリケーションのスコープが拡大するにつれてスキーマに変更を加える必要があり、さらに「custom_column」ソリューションの拡張と保守が困難です。最終的にはCustom_510になり、このテーブルがどれだけひどいものになるか想像してみてください。

まず、会社のスキーマを使用しましょう。

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

次に、すべての企業で使用/共有される最上位の必須属性にもユーザースキーマを使用します。

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

次に、各企業のカスタムユーザー属性に固有の動的属性を定義するテーブルを作成します。したがって、属性列の値の例は「LikeMusic」です。

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

次に、ユーザー属性値を保持するUserAttributesテーブルを定義します

[UserAttributes] UserAttributeDefinitionId, UserId, Value

これは、パフォーマンスを向上させるためにさまざまな方法で変更できます。UserAttributesに複数のテーブルを使用して、Valueに格納されるデータ型にそれぞれ固有のテーブルを作成したり、VarCharのままにしてキーバリューストアとして使用したりできます。

また、CompanyIdをUserAttributeDefinitonテーブルから将来の校正のために相互参照テーブルに移動することもできます。

NoSQLデータベースを使用します。会社とユーザーのドキュメントがあります。ユーザーは、ユーザーテンプレート（会社のフィールド/タイプを示すテキスト）に基づいてスキーマの一部を動的に作成します。

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

これは、Firebase.comのようなものでどのように見えるかということです。選択したものでそれを行う方法を学ぶ必要があります。

カスタムフィールドリクエストに頻繁に遭遇する場合、実際にはデータベースとほぼ同じようにモデル化します。各カスタムフィールド、CompanyCustomField（所属するユーザー、データ型など）に関するメタデータを保持するテーブルと、CustomerId、FieldId、および値を含む別のテーブルCompanyCustomFieldValuesを作成します。Microsoft Sql Serverのようなものを使用している場合、値列をsql_variantデータ型にする必要があります。

もちろん、管理者が各顧客のカスタムフィールドを定義できるインターフェイスと、このメタデータを実際に使用してフィールド値を収集するUIを構築する別のインターフェイスが必要になるため、これは簡単ではありません。また、フィールドのグループ化やフィールドの選択リストを行う必要があるなど、他の要件がある場合は、それに追加のメタデータ/他のテーブル（CompanyCustomFieldPickListOptionsなど）を含める必要があります。

これは簡単ではありませんが、新しいカスタムフィールドごとにデータベースの変更やコードの変更を必要としないという利点があります。カスタムフィールドの他の機能も同様にコーディングする必要があります（たとえば、文字列値を正規表現で検証する場合、特定の範囲内の日付のみを許可する場合、または別のカスタムフィールド値に基づいて1つのカスタムフィールドを有効にする必要がある場合） ）。

他の答えに代わる方法は、profile_attribと呼ばれるテーブル、またはスキーマがアプリケーションによって完全に管理される同様のテーブルを持つことです。

カスタム属性が追加されると、ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1)それらの削除を禁止できます。これは、柔軟性を提供しながら、結合を最小化します。

ちょっとしたトレードオフは、アプリケーションがデータベースに対してテーブルの変更権限を必要とすることであり、列名のサニタイズについては賢くする必要があると思います。

あなたの質問には多くの解決策があります。1つの解決策は、追加の属性をXMLとして保存することです。XMLはテキストとして保存できますが、XMLをXMLとしてサポートするデータベース（SQL Server）を使用している場合は保存できます。テキストとして保存すると、クエリ機能（カスタム属性での検索など）が制限されますが、保存と取得がすべて必要な場合は、優れたソリューションです。クエリが必要な場合は、XMLをXML型として保存することをお勧めします（ただし、これはよりベンダー固有です）。

これにより、顧客テーブルに追加列を追加するだけで、顧客に任意の数の属性を保存することができます。属性をハッシュセットまたはディクショナリとして保存できますが、すべてが最初は文字列であるため型安全性が失われますが、日付、数値、ブール値に標準形式の文字列を適用する場合はうまくいきます。

詳細については：

https://msdn.microsoft.com/en-us/library/hh403385.aspx

@WalterMittyの回答も有効です。ただし、多くの顧客が異なる属性を持っている場合、継承モデルに従うと多くのテーブルになる可能性があります。顧客間で共有されるカスタム属性の数に依存します。

会社プロファイルの異なるタイプごとに3つの異なるテーブルがあるように、データベースを正規化する必要があります。あなたの例を使用すると、列を持つテーブルがあります：

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

このアプローチは、企業が事前に保存したい情報の形を知っていて、頻繁に変更されないことを前提としています。設計時にデータの形状が不明な場合は、おそらくそのJSONフィールドまたはnosqlデータベースを使用する方が良いでしょう。

何らかの理由で、データベースは、内部プラットフォーム効果が最も頻繁に現れる1つのフィールドです。これは、アンチパターンがポップアップする別のケースです。

この場合、あなたは自然で正しい解決策と戦おうとしています。会社Aのユーザーは会社Bのユーザーではないため、独自のフィールド用に独自のテーブルが必要です。

データベースベンダーはテーブルごとに料金を請求することはなく、2倍のテーブルに2倍のディスク領域は必要ありません（実際、BのユーザーのAの属性を保存しないため、2つのテーブルを使用する方が効率的です。スペースが必要です）。

もちろん、十分な共通フィールドがある場合は、それらを共有ユーザーテーブルに含めて、会社固有の各ユーザーテーブルに外部キーを持つことができます。これは非常に単純な構造であるため、データベースクエリオプティマイザーがそれに苦労することはありません。必要なJOINは簡単です。

私のソリューションでは、プログラムからこのクエリを呼び出すことを想定しており、後処理を実行できるはずです。次の列を使用できます。

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUESは、キーと値のペアを格納する文字列型です。キーは列名になり、値は列値になります

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

このCUSTOM_VALUESには、存在する情報のみが保存されます。プログラムからクエリを実行するときに、この文字列を分割して使用できます。

私はこのロジックを使用してきましたが、問題なく動作します。クエリではなくコードでフィルタリングロジックを適用する必要があります。