さまざまなデータタイプの多対多の関係

Question

Googleのアプリは、数多くの異なるタイプの顧客を扱うようにカスタマイズされており、少数または1人の顧客のみに適用される特定の設定があります。 私は[設定]テーブルを追加して各設定を行にすることにしました。

[dbo].[Settings] 
    [SettingID] [int] 
    [SettingCode] [nchar](4) 
    [SettingDescription] [nvarchar](255) 

その後、多対多のテーブルを[顧客]テーブルにリンクされている

[dbo].[Customer_Settings] 
    [Customer_SettingsID] [int] 
    [CustomerID] [int] 
    [SettingID] [int] 

私の質問は、これらの設定の多くは、追加データを必要とするという事実をどのように扱うかについてです[Customer_Settings]テーブルに入力します。

たとえば、時刻データ型を必要とする「最新の配信時間」、またはintを必要とする「有効期限までの分」を設定することができます。これは悪いデザインのように思える

[dbo].[Customer_Settings] 
    [Customer_SettingsID] [int] 
    [CustomerID] [int] 
    [SettingID] [int] 
    [ValueTime] [time] NULL 
    [ValueInt] [int] NULL 
    ... 

：

これを処理する私は考えることができる2つの方法は次のように[Customer_Settings]テーブルにNULL可能列を追加することです。

私は考えることができる他の方法は次のように[Customer_Settings]テーブルに子テーブルを追加することです：それは正規化されただけでなく、面倒であるよう

[dbo].[Customer_Settings_Int] 
    [Customer_Settings_Int_ID] [int] 
    [Customer_SettingsID] [int] 
    [Value] [int] 

これがそうです。これらのいずれかが明らかに優れているかどうか、または別の方法があるかどうかを教えてください。ありがとう！

Answer 1

あなたが選んだ解決策はEntity-Attribute-Value (EAV.)です。最も一般的なアプローチは、すべての値を文字列として保存することです。正規表現のような式を含むバリデーター列を追加して、値を更新するクライアント関数またはt-sql関数によって検証される人もいます。

null可能な列を使用する方がはるかにクリーンです。

Answer 2

シングルトン属性のリストの代わりに、論理グループに属性の集合を集めることができるようです。あなたは、「配達されたもの」と「2つのそのようなグループになる可能性のあるもの」を暗示します。このようになりますルックアップテーブルにこれらのグループのリストを作成します。

ID Name   Description 
D Deliverable Something that is delivered 
E Expirable Something that expires 

そして、顧客のために交差点テーブルの種類を作成し、（グループ化のタイプと）グループ

create table CustGrouping(
    CustID int not null references Customer(ID), 
    GroupID int auto_generated, 
    GroupType char(1) not null references Groupings(ID), -- the table above 
    constraint PK_CustGrouping primary key(CustID, GroupID), 
    constraint UQ_Group_Type unique(GroupID, GroupType) 
); 

PKになります顧客が同じグループに複数回誤ってペアリングすることを防ぎます。 GroupID自体がユニークになるときに（GroupID、GroupType）に一意の制約を作成するのはなぜですか？したがって、それは外部キーの参照ポイントになることができます。

グループごとに別々のテーブルが必要です。

チェック制約は、そのテーブルに配信可能なデータを書き込む方法を示しています。ここ

は、操作のシーケンスである：

1. 成果は、顧客のために生成されると、顧客IDとグループ指定子（「D」）とCustGroupingに挿入します。これにより、この成果物のIDが生成されます。
2. 生成されたIDを使用して、成果物データを成果物テーブルに挿入します。

他のグループに対しても同じ操作が行われます。グループ化IDは、そのグループのFKが正しいタイプのグループのみを参照できることを確認します。また、どのテーブルにデータが含まれているかを知ることができ、このデータはグループ化の種類ごとに完全に異なる場合があります。新しいタイプのグループを追加し、グループ化テーブルに定義を挿入し、必要な長さとフォーマットのデータを含むテーブルを作成し、そこから移動するというスケーラビリティがあります。

また、グループごとに顧客データを表示するためのビューを作成することをお勧めします。たとえば、ビューCustomerDeliverablesは、成果物を含む顧客データを示します。だから、アプリケーションの一部が成果物を使って作業しているだけで、これがデータベースにどのように格納されているかの詳細を知る必要はありません。ビューのトリガーは、グループ化されたデータの作成、削除、および操作を容易にすることができます。