主キーとしてのEF4.0GUIDまたはInt

INT IDENTITYを使用して100％同意しますはるかに優れています！

GUIDは、主キーの自然な選択のように思われるかもしれません。本当に必要な場合は、テーブルの主キーにGUIDを使用することを主張できます。 やらないことを強くお勧めします GUID列をクラスタリングキーとして使用します、特に指定しない限り、SQLServerはデフォルトで実行します。

本当に2つの問題を区別する必要があります：

1）主キー は論理構造です。テーブル内のすべての行を一意かつ確実に識別する候補キーの1つです。これは実際には何でもかまいません-INT、GUID、文字列-シナリオに最も適したものを選択してください。

2）クラスタリングキー （テーブルの「クラスター化インデックス」を定義する1つまたは複数の列）-これは物理的 ストレージ関連のものであり、ここでは、小さくて安定した、増え続けるデータ型が最良の選択です-デフォルトオプションとしてINTまたはBIGINT。

デフォルトでは、SQL Serverテーブルの主キーはクラスタリングキーとしても使用されますが、そのようにする必要はありません。以前のGUIDベースのプライマリ/クラスター化キーを2つの別個のキー（GUIDのプライマリ（論理）キーと別個のINT IDENTITY（1）のクラスタリング（順序付け）キー）に分割すると、パフォーマンスが大幅に向上することを個人的に確認しました。 1）列。

Kimberly Tripp -インデックス作成の女王-および他の人が何度も述べています-クラスタリングキーとしてのGUIDは、そのランダム性のために、ページとインデックスの大規模な断片化につながり、一般的にパフォーマンスが低下するため、最適ではありません。

はい、わかっています-newsequentialid()があります SQL Server 2005以降では、それでも完全にシーケンシャルではないため、GUIDと同じ問題が発生しますが、それほど目立たないものです。

次に、考慮すべき別の問題があります。テーブルのクラスタリングキーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されるため、できるだけ小さくする必要があります。通常、大多数のテーブルには2億行以上のINTで十分です。また、クラスタリングキーとしてのGUIDと比較すると、ディスクとサーバーメモリに数百メガバイトのストレージを節約できます。

迅速な計算-プライマリキーおよびクラスタリングキーとしてINTとGUIDを使用：

1'000'000行のベーステーブル（3.8MB対15.26MB）
6つの非クラスター化インデックス（22.89MB対91.55MB）

合計：25MB対106MB -そしてそれはただ1つのテーブルにあります！

キンバリー・トリップの優れたものである、もう少し考えるべき食べ物を読んで、もう一度読んで、消化してください！これは、SQLServerのインデックス作成の福音です。