データベース設計の主キーとしての一意の識別子（GUID）

128ビットGUID（uniqueidentifier ）キーはもちろん32ビットのintの4倍です 鍵。ただし、いくつかの重要な利点があります。

• コンテンツをマージするときに「IDENTITYINSERT」の問題は発生しません
• NEWSEQUENTIALID（）の代わりにCOMB値を使用すると、「無料」のINSERTタイムスタンプが取得されます。 SELECTすることもできます いくつかの凝ったCAST()が必要な場合は、日付/時刻の範囲に基づいて主キーから 呼び出します。
• これらは世界的にユニークであり、時々非常に便利であることがわかります。
• 最高水準点を追跡する必要がないため、BLレイヤーはSQL Serverではなく値を割り当てることができ、SELECT scope_identity()の手順を省略できます。 挿入後に主キーを取得します。
• 20億を超えるレコードが存在する可能性がある場合でも、bigintを使用する必要があります。 （64ビット）intの代わりに 。それを行ったら、uniqueidentifier bigintの2倍の大きさです 。
• GUIDを使用すると、「IDを推測する」攻撃にさらされることなく、URLなどのキーをより安全に公開できます。
• SQL Serverがディスクからページをロードする方法と、プロセッサが現在ほとんど64ビットである方法との間で、数値が32ビットではなく128ビットであるからといって、比較に4倍の時間がかかるわけではありません。私が最後に見たテストでは、GUIDがほぼ同じくらい高速であることが示されました。
• インデックスのサイズは、いくつによって異なります。 列が含まれています。 GUID自体は大きくなりますが、余分な8バイトまたは12バイトは、インデックス内の他の列と比較して重要ではない場合があります。

結局、整数を使用してパフォーマンス上の小さな利点を絞り出すことは、GUIDの利点を失う価値がない場合があります。経験的にテストし、自分で決めてください。

個人的には、状況に応じて両方を使用していますが、私の場合、決定的な要因が実際にパフォーマンスに影響することはありません。