私たちはデータ マート/ウェアハウスのビルディング ブロックの設計を開始しており、すべてのタイム ゾーンをサポートできるようにする必要があります (クライアントは世界中にいます)。オンライン (および本) での議論を読むと、一般的な解決策は、ファクト テーブルに別の日付と時刻のディメンションとタイムスタンプを含めることのようです。
しかし、私が答えるのに苦労している質問は、動的なタイム ゾーンの要件を考慮して、日付と時刻のディメンションが実際にどのような利点があるかということです。時間ディメンションはもう少し理にかなっていますが、日付ディメンションには苦労しています。日付ディメンションの一般的な設計アプローチには、通常、曜日名、曜日、月名などのプロパティが含まれます。私が抱えている問題は、UTC で 2013 年 12 月 31 日火曜日の午後 11 時が水曜日であるということです。 、UTC+2 より後のすべてのタイム ゾーンで 2014 年 1 月 1 日。
したがって、すべてのクエリ (およびレポート) でこれらすべてのタイム ゾーン変換を行う必要がある場合、おそらく使用しない (ように思われる) これらのプロパティを保持して保存するポイントは何ですか? タイムゾーンごとにファクト行を作成することを提案する人もいますが、それはばかげているように思えます。毎月何百万ものレコードを保存できる必要があります。
タイム ゾーン ブリッジ テーブルを使用することを提案する人もいますが、これはある程度理にかなっていますが、クライアント アプリとレポートが日付から簡単に把握できるようにするために、複雑さと追加の結合が必要になるようです (レポートは主に Web ベースになります)。日付の変換、表示、書式設定を支援する無数のライブラリがあります)。
私が考えることができる唯一のことは、日付と時間でグループ化することの容易さとおそらくパフォーマンスですが、datepart でグループ化するのがいかに悪いか (私たちは MS SQL を使用していますが、数百万行をクエリします)、または検討する必要があります。月曜日などのほとんどのリテラルは、タイムゾーンが関係するときにあまり意味がないため、ほとんどの場合、時間、日、月、年の数字にすぎない非常に単純な日付と時刻の次元ですか?