EF 4.0 Guid oder Int als Primärschlüssel

Ich würde Ihnen zu 100 % zustimmen - die Verwendung einer INT IDENTITY ist viel besser!

GUIDs scheinen eine natürliche Wahl für Ihren Primärschlüssel zu sein - und wenn Sie es wirklich müssen, könnten Sie wahrscheinlich argumentieren, sie für den PRIMARY KEY der Tabelle zu verwenden. Was ich dringend empfehlen würde nicht zu tun Verwenden Sie die GUID-Spalte als Clustering-Schlüssel , was SQL Server standardmäßig tut, es sei denn, Sie weisen ausdrücklich darauf hin, dass dies nicht der Fall sein soll.

Sie müssen wirklich zwei Dinge auseinanderhalten:

1) der Primärschlüssel ist ein logisches Konstrukt – einer der Schlüsselkandidaten, der jede Zeile in Ihrer Tabelle eindeutig und zuverlässig identifiziert. Dies kann wirklich alles sein – ein INT, eine GUID, eine Zeichenfolge – wählen Sie, was für Ihr Szenario am sinnvollsten ist.

2) der Clustering-Schlüssel (die Spalte oder Spalten, die den "clustered index" in der Tabelle definieren) - dies ist ein physischer speicherbezogene Sache, und hier ist ein kleiner, stabiler, ständig wachsender Datentyp Ihre beste Wahl - INT oder BIGINT als Ihre Standardoption.

Standardmäßig wird der Primärschlüssel einer SQL Server-Tabelle auch als Clusterschlüssel verwendet – aber das muss nicht so sein! Ich persönlich habe massive Leistungssteigerungen gesehen, als ich den vorherigen GUID-basierten Primär-/Clusterschlüssel in zwei separate Schlüssel aufgeteilt habe – den primären (logischen) Schlüssel auf der GUID und den Clusterschlüssel (Ordnungsschlüssel) auf einem separaten INT IDENTITY(1, 1) Spalte.

Als Kimberly Tripp - die Queen of Indexing - und andere haben es schon oft gesagt - eine GUID als Clustering-Schlüssel ist nicht optimal, da sie aufgrund ihrer Zufälligkeit zu einer massiven Seiten- und Indexfragmentierung und zu allgemein schlechter Performance führt.

Ja, ich weiß - es gibt newsequentialid() in SQL Server 2005 und höher - aber selbst das ist nicht wirklich und vollständig sequentiell und leidet daher auch unter den gleichen Problemen wie die GUID - nur etwas weniger prominent.

Dann gibt es noch ein weiteres Problem zu beachten:Der Clustering-Schlüssel einer Tabelle wird auch zu jedem einzelnen Eintrag in jedem nicht gruppierten Index Ihrer Tabelle hinzugefügt - daher möchten Sie wirklich sicherstellen, dass er so klein wie möglich ist. Typischerweise sollte ein INT mit mehr als 2 Milliarden Zeilen für die überwiegende Mehrheit der Tabellen ausreichen – und im Vergleich zu einer GUID als Clustering-Schlüssel können Sie sich Hunderte von Megabyte Speicherplatz auf der Festplatte und im Serverspeicher sparen.

Schnelle Berechnung - mit INT vs. GUID als Primär- und Clusterschlüssel:

Basistabelle mit 1.000.000 Zeilen (3,8 MB vs. 15,26 MB)
6 Nonclustered-Indizes (22,89 MB gegenüber 91,55 MB)

GESAMT:25 MB gegenüber 106 MB - und das nur auf einem einzigen Tisch!

Noch ein paar Denkanstöße - ausgezeichnetes Zeug von Kimberly Tripp - lesen Sie es, lesen Sie es noch einmal, verdauen Sie es! Es ist wirklich das Evangelium der SQL Server-Indizierung.