GUID が大好きです。ただし、最近、主キーのIDENTITYに対する実際の長所/短所を理解するためにいくつかの調査を行っており、それを非常にうまくまとめたこの記事を見つけました。
記事の中で、著者は次のように述べています。
- データ ウェアハウジングに非常に役立ちます。
GUID よりも IDENTITY を使用する利点の 1 つとして。
データ ウェアハウスのように、特に大規模なデータベースではサイズが重要であることは理解できますが、この記事では説明できない理由が他にもあるようです。だから私は尋ねます：
GUID がデータ ウェアハウジングに適していないのはなぜですか?
GUIDは、主キーの自然な選択のように思われるかもしれません。本当に必要な場合は、テーブルの主キーにGUIDを使用することを主張することもできます。特に指定しない限り、GUID列をクラスタリングキーとして使用することを強くお勧めします。これは、SQLServerがデフォルトで使用します。
あなたは本当に2つの問題を区別する必要があります：
1）主キーは論理構造であり、テーブル内のすべての行を一意かつ確実に識別する候補キーの1つです。これは何でもかまいません。実際には、INT、GUID、文字列など、シナリオに最も適したものを選択してください。
2）クラスタリングキー（テーブルの「クラスター化インデックス」を定義する1つまたは複数の列）-これは物理ストレージ関連のものであり、ここでは、小さく、安定した、増え続けるデータ型が最適です-INTまたはデフォルトオプションとしてBIGINT。
デフォルトでは、SQL Serverテーブルの主キーはクラスタリングキーとしても使用されますが、そのようにする必要はありません。以前のGUIDベースのプライマリ/クラスター化キーを2つの別個のキー（GUIDのプライマリ（論理）キーと別個のINT IDENTITY(1,1)列のクラスター化（順序付け）キー）に分割すると、個人的に大幅なパフォーマンスの向上が見られました。
キンバリー・トリップ（インデックス作成の女王）などが何度も述べているようGUIDに、クラスタリングキーは最適ではありません。ランダムであるため、ページとインデックスの断片化が大きくなり、一般的にパフォーマンスが低下するためです。
はい、私は知っnewsequentialid()ています-SQL Server 2005以降にあります-しかし、それでも完全にシーケンシャルではないため、-と同じ問題が発生しますGUID-少し目立たないほどです。
次に、考慮すべき別の問題があります。テーブルのクラスタリングキーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されます。したがって、可能な限り小さいことを確認する必要があります。通常、テーブルの大部分には2億行以上のINTで十分です。また、クラスタリングキーとしてのGUIDと比較すると、ディスクとサーバーメモリに数百メガバイトのストレージを節約できます。
迅速な計算-プライマリキーおよびクラスタリングキーとしてINTとGUIDを使用：
合計：25MB対106MB-そしてそれはただ1つのテーブルにあります！
もう少し考えてみてください-キンバリー・トリップの素晴らしいもの-読んで、もう一度読んで、消化してください！これは、SQLServerのインデックス作成の福音です。
マーク
IDENTITY フィールドは、小さくてきれいなインデックスを作成します。また、これらは SEQUENTIAL です。つまり、それらのために作成されたインデックスは、通常の GUID キー インデックスより断片化されていません。SEQUENTIAL GUID を使用すると、この動作に近づくことができますが、それでも欠点があります。GUID の利点の 1 つは、データベース間でも一意になる傾向があることですが、ほとんどのアプリケーションではパフォーマンスとスペースに影響を与えます。
GUID の長所 すべてのテーブル、すべてのデータベース、すべてのサーバーで一意 異なるデータベースからのレコードを簡単にマージできる 複数のサーバー間でデータベースを簡単に分散できる データベースへのラウンドトリップの代わりに、どこでも ID を生成できる ほとんどのレプリケーション シナリオではとにかく GUID 列が必要
GUID の短所 従来の 4 バイトのインデックス値よりも 4 倍も大きくなります。注意しないと、これはパフォーマンスとストレージに深刻な影響を与える可能性があります デバッグが面倒です (userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}') SQL 2005) およびクラスター化インデックスの使用を有効にする
また、あなたの質問に具体的に答えるために：あなたが参照している記事では、「ID」フィールドは自然キーよりもデータウェアハウジングに役立つと言っているのと同じくらい、「GUIDはデータウェアハウジングにとって悪い考えです」と言っているとは思いません。ただし、データ ウェアハウスに大量のレコードを格納している場合は、上記のインデックス作成に関する不満により、GUID ではなく IDENTITY 列を使用することで、パフォーマンスが向上し、必要なストレージが少なくなります。これが主な欠点だと思います。
4 バイトの整数を使用する主な理由は、行のサイズを最小限に抑えようとするためです。ファクト テーブルに数億の行を含めることができることを考えると、1 行あたり 12 バイトの節約はかなりの節約になります。
もちろん、それはあなたが2 ^ 31 - 1行未満であることを前提としています...
また、(既定のクラスター化インデックスを使用して) ID 列に挿入してもページ分割は発生しませんが、GUID 列にクラスター化インデックスを挿入するとページ分割が発生します。
参照 : SQL Server: UniqueIdentifier (GUID) を主キーとして使用してもよろしいですか?
厳密に言えば、サロゲート/ファクトIDキーは匿名で無意味である必要がありますが、非常に大きなファクトでは、リポーリングが広範囲の日付に基づいているため、日付のサロゲートキーを日付を表す整数（例：20120830）にすると、カレンダーディメンションに実際に参加せずにクエリを実行します。GUIDを使用してこの（疑わしい）トリックを実行することはできません。また、ディメンションで不明なメンバーのセットがあると便利です。たとえば、カレンダーディメンションでは、サロゲート0は「日付がまだ利用できない」を意味し、-1は「不明」を意味し、-2は「遅い日付」を意味する場合があります-つまり、カレンダー範囲の最大の日付より後です。-3は、「早い日付」などを意味する場合があります。これは、GUIDを使用すると問題が発生する可能性があります。
あなたの質問を読んだ後、私はいくつかの考えを得る
GUID は主に MS の世界で使用されています..DWH の 12 年以上の経験で使用されている GUID は見られません...
ID 列はおそらくテーブルのサロゲート キーになるでしょう。自動インクリメントを使用する方がはるかに理にかなっています... GUID がそのような機能を提供できるかどうかはわかりません...
数値列のインデックス作成は、英数字列のインデックス作成よりもはるかに高速です..数値列ベースのインデックスは、サイズが小さく、アクセスが高速です...
h番目
Identity のインデックス作成は、GUID のインデックス作成よりも非常に効率的であるためです。