Als Primärschlüssel im logischen Sinne (eindeutig identifiziert Ihre Zeilen) - ja, absolut, macht total Sinn.
ABER: in SQL Server, ist der Primärschlüssel standardmäßig auch die Clustering-Schlüssel auf dem Tisch, und mit einem ROWGUID als den Clustering-Schlüssel ist eine wirklich, wirklich schlechte Idee. In Kimberly Tripps exzellentem Artikel GUIDs as a PRIMARY and/or the clustering key finden Sie ausführliche Gründe, warum Sie keine GUIDs für Clustering verwenden sollten.
Da die GUID per Definition zufällig ist, haben Sie eine schreckliche Indexfragmentierung und somit wirklich sehr schlechte Leistung beim Einfügen, Aktualisieren, Löschen und Auswählen von Anweisungen.
Da der Clusterschlüssel zu jedem Feld jedes nicht gruppierten Indexes in Ihrer Tabelle hinzugefügt wird, verschwenden Sie viel Speicherplatz - sowohl auf der Festplatte als auch im Arbeitsspeicher des Servers Verwenden von 16-Byte-GUID vs. 4-Byte-INT.
Also: ja, als ROWGUID hat ein ROWGUID seine Vorzüge - aber wenn Sie es verwenden, vermeiden Sie definitiv die Verwendung dieser Spalte als Clustering-Schlüssel in der Tabelle! Verwenden Sie eine INT IDENTITY() oder etwas ähnliches dafür.
Für einen Clustering-Schlüssel, im Idealfall sollten Sie für vier Merkmale aus:
- stabil (Wechsel nie)
- einzigartige
- so klein wie möglich
- ständig wachsende
INT IDENTITY() ist ideal für diesen Bedarf. Und ja - der Clustering-Schlüssel muss eindeutig sein, da er zum physischen Suchen einer Zeile in der Tabelle verwendet wird. Wenn Sie eine Spalte auswählen, die nicht eindeutig sein kann, fügt SQL Server Ihrem Clustering-Schlüssel tatsächlich einen Vier-Byte-Unifier hinzu - wieder, nicht etwas, was Sie haben wollen ....
Schauen Sie sich The Clustered Index Debate Continues - ein weiterer wundervoller und aufschlussreicher Artikel von Kim Tripp (die "Königin der SQL Server Indizierung"), in dem sie alle diese Anforderungen sehr schön und gründlich erklärt .
MArc
Die Größe der GUID sollte hier kein Problem sein. In der direkten Antwort auf die Frage gibt es hier nichts außer einer Warnung "Vergessen Sie nicht, einen anderen gruppierten Index zu wählen". Da der ROWGUID intern auch die Zeilen-ID ist, sollte kein Speicherplatz verschwendet werden, da das Ziel des Index (die ID der Zeile) trotzdem dort hineingeschrieben wird. Oder gibt es eine Einschränkung/einen Mangel an Optimierung, was bedeutet, dass MS die GUID zweimal in den Index schreiben muss, selbst wenn es die ROWGUID ist? Ich würde es bezweifeln, aber bitte erkläre, ob du etwas anderes weißt. –
@CodeChief: die Größe des * Clustering-Schlüssels * ist ** sehr viel ** ein Problem in SQL Server! Es sollte wirklich so klein wie möglich sein, da es auch in ** all ** nonclustered Indizes für die gleiche Tabelle enthalten ist. 4 Byte vs. 16 Byte macht einen ** großen ** Unterschied, wenn Sie 100 Millionen Zeilen und 15 Nonclustered-Indizes haben! –
für den Fall, dass es nicht klar war ich wirklich vorschlagen, das hat nichts mit Clustered-Indizes zu tun! Wenn Sie dann müssen DEFAULT NEWSEQUENTIALID() wie in MSDN dokumentiert und bereits von anderen hier beantwortet. Wenn man über große Datenbanken spricht, wenn es sich um große Kunden handelt und wichtig ist, dann sollte man auf Skalierbarkeit oder hohe Verfügbarkeit als Voraussetzung achten, was sowieso zu ROWGUID zurückführt. –