0

クラスター化された複合主キーを持つ1億1100万行を超えるトランザクションテーブルがあります...

RevenueCentreID  int
DateOfSale       smalldatetime
SaleItemID       int
SaleTypeID       int

...SQL 2008 R2 データベースで。

アーカイブ プロジェクトのためにすぐにテーブルを切り捨てて再入力する予定です。そのため、インデックスを正しく取得する機会は、テーブルが切り捨てられてからになります。複合主キーを保持した方がよいでしょうか、それとも一意の自動インクリメント主キーに移行する必要がありますか?

テーブルのほとんどの検索は、DateOfSale 列と RevenueCentreID 列を使用して行われます。また、SaleItemID 列に参加することもよくあります。SaleType 列を使用することはほとんどありません。実際、一意性のために主キーに含まれているだけです。新しい売上高の挿入と削除にかかる時間（一晩で行われる）は気にしませんが、レポートを返す速度は気にしません。

4

3 に答える 3

1

では、自然キーと代理キーの両方が必要であり、必要であることを学びました。

自然キーは、ビジネス キーを一意に保ち、インデックス作成に最適です。代理キーはクエリと開発に役立ちます。

したがって、あなたの場合、サロゲート自動インクリメントキーは、データのすべての行をそのまま維持するのに役立つという点で優れています。また、DateOfSale、RevenueID、およびおそらく ClientID の自然キーは、重複レコードが保存されていないことを確認し、自然キーにインデックスを付けることができるため、クエリを高速化する優れた方法になります。

于 2011-06-27T11:31:11.473 に答える
1

ここでは、代理キーは役に立ちません。リストされている列のクラスター化された主キーと、のインデックスをお勧めしますSaleItemID。

于 2011-06-27T11:32:04.787 に答える
0

挿入と削除の速度を気にしない場合は、クエリを正確に対象とする複数のインデックスが必要になるでしょう。

提案どおりに自動インクリメント主キーを作成できますが、レポートクエリをカバーするために必要に応じてインデックスを作成することもできます。一意性を強制するために、現在キーにある列に一意の制約を作成します。

インデックス チューニング ウィザードは最適なインデックス セットの定義に役立ちますが、独自のインデックスを作成することをお勧めします。

経験則 - インデックスを作成する列を定義し、列を「含める」こともできます。

レポートの列に OrderBy または Where 句がある場合は、これらに対してインデックスを定義する必要があります。選択で返されるその他のフィールドは、列に含める必要があります。

于 2011-06-27T11:26:40.260 に答える