静的なディメンションであり、時間の経過とともに変化しない単純なディメンション、たとえば日付ディメンションがあります。ファクトテーブルには、いくつかの日付があります。
1つの日付ディメンションに2回結合するのと、その日付ディメンションの2番目のコピーを作成して2番目の日付に結合するのとでは、パフォーマンスの観点では違いますか?
次のようなファクトテーブルがある場合:
FactId FactNumber FactDate FactOtherDate
1 10 1/1/2016 12/31/2015
...そして私はこのようなクエリを作りたいです:
Select Sum(FactNumber), DateDim.Month, OtherMonth = DateDim2.Month
From Fact
Inner Join DateDim On DateDim.Date = FactDate
Inner Join DateDim DateDim2 ON DateDim2.Date = FactOtherDate
Group By DateDim.Month, DateDim2.Month
...同じテーブルに2回結合するよりも、2番目の実際のテーブルを作成して結合する方がよいでしょうか。
インデックス付きビューは、ビューとしてのクエリを許可しないため、SQL Serverが異なる方法で、おそらく効率が悪い方法で処理すると思いました。インデックス付きビューを使用するつもりはありません。その制限がこの質問への洞察を提供するかどうか疑問に思っています。
インデックス付きビューにできるものには、多くの制限があります。データウェアハウスの設定では、これらの制限により、ほぼすべての標準スター結合ビューをインデックス付きビューにすることが不可能になります。コメントが言っていることにもかかわらず、[マテリアライズド]インデックス付きビューは魔法なので、これは本当に残念です。
同じテーブルに2回参加することが問題になるかどうかは問題ではありません。データウェアハウスでは、時間と日付のディメンションに何十回も参加していることがよくあります。
また、日付ディメンションの主キーを日付自体にしたことにも興味がありました。最後のデータウェアハウスでは、すべての日付部分が不明である不確定な日付(2016/1/??など)を保存する必要があったため、INT列を主キーとして使用する必要がありました。
また、ビューを作成するときは、常に同じ結果が得られる場合でも、LEFT JOINがINNER JOINよりもパフォーマンスが優れているかどうかを確認する必要があります。私たちのデータウェアハウスがスノーフレークスキーマに近かった頃、結合は数百になり、多くのビューはすべてのLEFT JOINでより適切に機能しました。INNERJOINはINNER JOINが適切でした。