短期間に大量のデータを保存する場合の主キー

Question

エラーメッセージを一時的に保存するためのテーブルの作成方法に疑問があります。

1. インサートの多くと外部キーとして
2. A GUIDを削除し、外側に残される可能性があれば、
3. 主キーにErrorMessage

するための単純なデータ型はnvarcharのフィールドに入社し、私は短期間に大量のデータを保存するためにインデックスを使用する必要がありますか？

おかげ

Answer 1

私はジェイに同意しません - キム・トリップのThe Clustered Index Debate continuesをチェックしてください。とりわけ

、彼女は良い主/クラスタ化キーを持つと言う（INTのIDENTITYカラム上で - ませ GUID列を）を実際に挿入をスピードアップし、削除します。

テーブルを短時間しか使用しない場合でも、良い、高速の主キーとクラスタードインデックスを得るには、TableID INT IDENTITY(1,1) PRIMARY KEY列を使用することをお勧めします。インサートを遅くします）。

GUID列を外部キーとして参照する頻度によっては、インデックスを追加することもできます。これは、検索が高速になるためです。

大量のデータを一括してロードする場合（一度に何千もの行が表示されます）、ロード前にそのインデックスを削除し、データがロードされると再作成することも考えられますすべての時間にそれを持っているよりも速く） - しかし、もう一度：それはあなたがロードしているデータの量と、どのくらいの頻度でいるかに依存します。

Marc

Answer 2

私はあなたがそれに基づいてエラーを検索しようとしているので、あなたのGUID外国IDフィールドにインデックスを置きます。 主キーと同じです。主キーの必要性を強制する要件について言及していません。そしてそれはちょっと余計なオーバーヘッドを追加します。 しかし、おそらくソートを行う必要があります。そのためには、数値フィールドまたは日付フィールドが必要です。私はテーブルに数値フィールドを追加するだけでよいので、注文メッセージに基づいてソートすることができます。しかし、データが長続きしないので、おそらくそのフィールドを主フィールドにする必要はありません。