テーブルで Int / GUID のどちらを使用すべきかという質問があります。このシナリオを使用します。
主キーとしてa を使用しBIGINTます – クラスタ化など、結合、高速検索などに使用します。つまり、これは検索とユーザーの利便性のために最適化されています。
をGUIDレコードの一意のマーカーとして使用します。これは、サーバー/アプリケーションなどにデータを移植するときに使用するものです。これはユーザーには表示されませんが、すべてのレコードにスタンプされます。
これにより、両方の長所が得られます。主キーとして使用することによる断片化とパフォーマンスへの影響を回避GUIDsできますが、レコードを個別に識別できるため、データを移動したりシステム間で共有したりするときにその利点を維持できます。
追加のストレージ コストが高すぎると主張する人もいるかもしれませんが、同じデータ列で 2 つの異なることを試みるよりも、SAN に数ドル余分に費やす方が長期的には安くなると思います。
私は個人的INT IDENTITYに、主キーとクラスタリング キーのほとんどに使用しています。
論理構造である主キーを区別する必要があります。行を一意に識別し、一意で安定している必要がありNOT NULLます。AGUIDは一意であることが保証されているため、主キーにも適しています。SQL Server レプリケーションを使用する場合は、主キーとしてAGUIDを選択することをお勧めします。その場合、GUIDとにかく一意に識別する列が必要になるためです。
SQL Serverのクラスタリング キーは、データの物理的な順序付けに使用される物理的な構成要素であり、正しく理解するのははるかに困難です。通常、SQL Server のインデックス作成の女王である Kimberly Tripp も、適切なクラスタリング キーが一意で安定していて、可能な限り狭く、理想的には増加し続けることを必要とします (これは aINT IDENTITYです)。
インデックス作成に関する彼女の記事を参照してください。
Jimmy Nilsson のThe Cost of GUIDs as Primary Keyも参照してください。
GUID は、クラスタリング キーとしては非常に不適切な選択です。GUID は幅が広く、完全にランダムであり、インデックスの断片化が悪化し、パフォーマンスが低下するためです。また、クラスター化キー行は、すべての非クラスター化 (追加) インデックスのすべてのエントリにも格納されるため、実際には小さくしておく必要があります。GUID は 16 バイトであるのに対し、INT は 4 バイトです。いくつかのクラスター化されていないインデックスと数百万行の場合、これは大きな違いになります。
SQL Server では、主キーは既定でクラスタリング キーですが、そうである必要はありません。GUID を NON-Clustered プライマリ キーとして、INT IDENTITY をクラスタリング キーとして簡単に使用できます。少し意識するだけで済みます。