データ ウェアハウスで、ファクト テーブルにクラスター化インデックスを作成することには欠点がありますか? (ほとんどの場合、日時列にあります)
「デフォルトで...」に「はい」または「いいえ」と答えますか?
デフォルトでクラスター化インデックスを作成すべきでないとしたら、それはなぜですか? (クラスター化インデックスの長所は知っていますが、短所は何ですか?)
参考文献
http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/11/365.aspx
特定の値で頻繁に検索されるテーブル (トランザクションまたはウェアハウス) にクラスター化されたインデックスを作成することを常にお勧めします。クラスター化されたインデックス (または任意のインデックス) の欠点は、スペースを占有する追加のデータ ストアを作成することです。インデックスが作成されているテーブルが巨大な場合...インデックスも巨大になります! インデックスが多いほど、データベースに加えて保存するデータが多くなります。ただし、検索の速度が必要な場合は、その速度を向上させるためにインデックスが必要になる場合があります。
ただし、テーブルの ID にクラスター化インデックスを作成することもできます。次に、Lucene (または Lucene.NET) などの製品で、データベースの外部にインデックスを作成します。次に、Lucene インデックス (検索に関しては柔軟性と機能がはるかに優れています) を検索できます。これにより、特定のレコード (または複数のレコード) の ID が返され、データベースで必要なデータを識別するために使用できます。これは、現在のプロジェクトでかなり使用したルートであり、非常にスムーズに機能することを認めなければなりません! インデックスの作成はかなり高速です (特に、SQL Server で FullText オプションを使用する場合と比較した場合)。考慮すべきことだけです。
alwaysとneverとは言いたくありませんが、ほとんどの場合、ファクト テーブルでクラスター化インデックスを使用することは良いことだと思います。ランダムな値が挿入される列の種類にクラスター化インデックスを作成することはお勧めしません。たとえば、GUID などのクラスター化インデックスは必要ありません。日付とシーケンシャル ID は、クラスター化インデックス、特に範囲クエリに最適です。
クラスター化インデックスの長所を知っていると述べましたが、短所に関する限り、それらが短所であるかどうかについて、それらをどのように使用するかによって実際に決定されます。
1.) インデックスの順序に一致するようにデータ ブロックのレイアウトを変更するため、テーブルごとにクラスター化インデックスを 1 つだけ持つことができます。これが、クラスター化インデックスが範囲クエリに最適な理由です
2.) データ ブロックはインデックスの順序で配置されるため、キーの順序を変更する挿入と更新により、データ ブロックを物理的に変更して、インデックスとの順序を維持することができます。キー値を順番に挿入すると、この短所を軽減できます。
int (bigint)自動インクリメント PK クラスター化インデックスを使用すると、パーティショニングが大幅に簡素化されます。遅かれ早かれ、ファクト テーブルはこの時点に到達します。ですから、今は必要ないかもしれないと思っても、作成してください。