本の中で私は、時間を別々の列に分割すると、それが実際のパフォーマンスの向上になると読みました。たとえば、日、月、年など...
データベースには、時間列のインデックスを処理するためのスマートなアプローチがすでにあるので、時間を分割して数百万のインデックスバリアントを追加することは廃止されていますか？
パフォーマンスの違いの経験はありますか？
考えられるクエリは、月曜日の朝の13：00〜14：00の売上です。
4 に答える
2
このSOの質問/回答を見てください。
于 2011-03-04T12:23:37.260 に答える
0
概説した特定のシナリオ（毎週月曜日の13：00〜14：00）は、日時データに対する通常のインデックスでは適切に処理できません。
その情報を取得するには、日時データを曜日と時間の部分に細かく分析する必要があります。このシナリオでは、曜日と時刻（時間）の列に分割すると、はるかにうまく機能し、個別に、または複合として（両方にわたって）インデックスを作成できます。
パフォーマンスは大きく異なります-曜日+時刻のインデックスを使用して、データの1/168（理論上の平均）またはより現実的にはデータの約1/50（労働時間）を見る代わりに、クエリそれ以外の場合は、2つの変換を実行して（曜日+時刻コンポーネントを取得するため）、それをフィルターで実行する必要があります。
于 2011-03-04T11:16:55.667 に答える
0
多くのスタースキーマでは、時間ディメンションがあると便利です。そのディメンションテーブルでは、曜日、月などを明示的にレイアウトすると便利な場合があります。これらの属性の多くは、SQLの方言に組み込まれている関数からアクセスできます。また、このデータを具体化する場合よりも、関数を使用する場合の方がディスクI/Oが少なくて済みます。ただし、カレンダー関数がデータのように見える場合は、特定のタイムスライスでレポートを作成する方法が非常に簡単になります。
これが本当に役立つのは、企業に独特の「会社キャンレンダー」があり、日付が「会計四半期」と呼ばれる単位に属することができ、日-月-年に簡単にマッピングできない場合です。すべてのカレンダーの癖を、時間ディメンションテーブルを生成する単一のプログラムに入れると、ウェアハウスコードの残りの部分が非常にクリーンになります。
他のディメンションテーブルと同様に、粒度を正しく設定することが非常に重要です。1日に1行だけが必要な場合は、3,650行をわずかに超える10年分の日付を保存できます。これは、今日の基準では小さなテーブルです。場合によっては、「シフト」（8時間の期間）が適切な粒度であることが判明します。データの用途によって異なります。
どちらの方向に進んでも、ウェアハウスをセットアップするときにデータが「変換」される準備をし、予期しない要件に直面したときに「試行」に直面する準備をします。
于 2011-03-04T11:30:57.050 に答える
0
関数ベースのインデックスは、可能なオプションの1つです。インデックス付きビューは別のものです。
新しい属性を作成するだけでは、パフォーマンスが向上するわけではありません。パフォーマンスの違いは、データの保存方法とインデックス作成方法の根本的な変更によるものです。したがって、日付と時刻の列を個別に作成するとパフォーマンスが向上すると言うのは誤解を招き、非常に単純すぎます。ただし、他の理由から、別の時間列を作成することをお勧めします。たとえば、明確にする、クエリロジックを単純化する、DBMSの日付/時刻タイプやその他の機能を最大限に活用するなどです。
于 2011-03-04T11:43:20.300 に答える