複数のアウトリガーテーブルを1つにまとめる？

Question

私は次元テーブルといくつかのアウトリガーを持っています。

create table dimFoo (
    FooKey int primary key, 
    ...... 
) 

create table triggerA (
    FooKey int references dimFoo (FooKey), 
    Value varchar(255), 
    primary key nonclustered (FooKey, Value) 
) 

create table triggerB (
    FooKey int references dimFoo (FooKey), 
    Value varchar(255) 
    primary key nonclustered (FooKey, Value) 
) 

create table triggerC (
    FooKey int references dimFoo (FooKey), 
    Value varchar(255) 
    primary key nonclustered (FooKey, Value) 
) 

これらのアウトリガーテーブルを1つのテーブルにマージする必要がありますか？

create table Triggers (
    FooKey int references dimFoo (FooKey), 
    TriggerType varchar(20), // triggerA, triggerB, triggerC, etc.... 
    Value varchar(255), 
    primary key nonclustered (FooKey, TriggerType, Value) 
)   

Answer 1

顧客が潜在的に複数の趣味を有するようdimCustomerと同様のシナリオのこの種を満たすために、典型的なキンボールアプローチは寸法（dimCustomerとdimHobby）との間のブリッジ・テーブルを使用することです。

This linkは、ブリッジテーブルがどのようにこの問題を解決できるか、そしてより良い結果を得る代替案をまとめたものです。

ビジネス要件が何であるか、これらの価値タイプの数、さまざまな価値タイプと価値がどのように「統一されているか」、および使用するBIテクノロジデータにアクセスすることは、さまざまな多人数の人に対応する1つのUberブリッジにブリッジを組み込むべきかどうかに決定的な答えを与えることは困難です。上記のすべてがある程度答えに影響します。

一般に、「ジェネリックテーブル」のアプローチは、アナリティクスのプレゼンテーションの場合よりも、管理の場面の方でより便利です。私のデフォルトのアプローチは、ETLの観点から管理できなくなったり、ユーザーの問合せの観点からはるかに複雑に感じられるまで、特定のブリッジ・テーブルを作成することです。私はget-goから組み合わされたテーブルに「最適化」するつもりはないだろう。

あなたの状況が普通の基準（あなたの例のように3つ、または10つ）を超えている場合、組み合わせると良い考えになるかもしれません。これにより、dimCustomer、dimValueType、dimValueのディメンションを使用すると、それは事実のない事実のようになり、完全に合理的な解決策になります。