Ich implementiere benutzerdefinierte ASPNetMembership mit EF 4.0
Gibt es einen Grund, warum ich Guid als Primärschlüssel in Benutzertabellen verwenden sollte?
Soweit ich weiß, Int als eine PK auf SQL Server mehr Leistung als Strings.
Und Int ist einfacher zu iterieren. Auch aus Sicherheitsgründen, wenn ich irgendwo eine int-ID übergeben muss, z. B. in der URL, kann ich sie irgendwie verschlüsseln und sie wie eine Zeichenfolge ohne Probs weitergeben.
Aber wenn ich automatisch generierte Guid auf SQL Server-Seite mit EF 4.0 verwenden möchte, muss ich diesen Trick tun Ссылка
Ich kann keine Fälle sehen, warum ich Guid als PK verwenden sollte, kann nur eins sein, wenn das System Millionen und Millionen Benutzer haben wird, aber auch, theoretisch könnte Guid irgendwann dupliziert werden, ist das nicht so?
Wie auch immer die Int32-Größe 2,147.483,647 ist, ist es ziemlich genau für ein sehr-sehr großes System, aber wenn diese Anzahl immer noch nicht genug ist, kann ich mit Int64 gehen, in diesem Fall kann ich 9.223.372.036.854.775.807 Zeilen haben. Ziemlich viel, oder?
Andererseits verwendet M $ Guids als PK in ihrer ASPNetMembership-Implementierung. [aspnetdb]. [aspnet_Users] - & gt; PK UserId Typ uniqueidentifier, sollte einige Gründe / Erklärung warum das getan haben?!
Kann irgendjemand irgendwelche Ideen / Erfahrungen dazu haben?
Ich würde Ihnen zu 100% zustimmen - die Verwendung eines INT IDENTITY ist viel besser!
GUIDs scheinen eine natürliche Wahl für Ihren Primärschlüssel zu sein - und wenn Sie wirklich müssen, könnten Sie wahrscheinlich argumentieren, sie für den PRIMÄRSCHLÜSSEL der Tabelle zu verwenden. Was ich sehr empfehlen sollte nicht zu tun ist die GUID-Spalte als Clustering-Schlüssel zu verwenden, was SQL Server standardmäßig tut, es sei denn, Sie sagen es ausdrücklich nicht.
Sie müssen wirklich zwei Ausgaben auseinander halten:
1) Der Primärschlüssel ist ein logisches Konstrukt - einer der Kandidatenschlüssel, der jede Zeile in Ihrer Tabelle eindeutig und zuverlässig identifiziert. Das kann alles sein, wirklich - ein INT, eine GUID, eine Zeichenkette - wählen Sie aus, was für Ihr Szenario am sinnvollsten ist.
2) der clustering key (die Spalte oder die Spalten, die den "clustered index" in der Tabelle definieren) - dies ist eine physische speicherbezogene Sache und hier Ein kleiner, stabiler, ständig wachsender Datentyp ist Ihre beste Wahl - INT oder BIGINT als Standardoption.
Standardmäßig wird der Primärschlüssel in einer SQL Server-Tabelle auch als Clustering-Schlüssel verwendet - das muss aber nicht so sein! Ich habe persönlich massive Leistungszuwächse erlebt, als ich den vorherigen GUID-basierten Primär / Clustered-Schlüssel in zwei separate Schlüssel aufteilte - den primären (logischen) Schlüssel auf der GUID und den Clustering (ordering) -Schlüssel auf einer separaten INT IDENTITY (1, 1) Spalte.
Als Kimberly Tripp - Die Königin der Indizierung - und andere haben schon oft gesagt - eine GUID als Clustering-Schlüssel ist nicht optimal, da sie aufgrund ihrer Zufälligkeit zu massiver Seiten- und Indexfragmentierung und generell zu 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: Der Clustering-Schlüssel einer Tabelle wird jedem einzelnen Eintrag in jedem und jedem nicht gruppierten Index in Ihrer Tabelle hinzugefügt - Sie sollten also wirklich sicherstellen, dass er so klein wie möglich ist . In der Regel sollte ein INT mit 2+ Milliarden Zeilen für die überwiegende Mehrheit der Tabellen ausreichen - und im Vergleich zu einer GUID als Clustering-Schlüssel können Sie Hunderte von Megabyte Speicherplatz auf der Festplatte und im Serverspeicher sparen.
Schnelle Berechnung - mit INT vs. GUID als Primary und Clustering Key:
GESAMT: 25 MB vs. 106 MB - und das nur auf einem einzigen Tisch!
Etwas mehr zum Nachdenken - hervorragende Sachen von Kimberly Tripp - lesen Sie es, lesen Sie es noch einmal, verdauen Sie es! Es ist die SQL Server-Indizierung Gospel, wirklich.
Geh mit dem INT PK. Siehe Kimberly L. Tripps Artikel: GUIDs als PRIMARY KEYs und / oder der Clustering-Schlüssel
Bis Entity Framework ein Konzept der Stapelverarbeitung einführt, gibt es keinen Grund dafür, INT IDENTITY nicht zu verwenden. Guid ist nur nützlich, wenn Sie die ID des neuen Datensatzes auf dem Client festlegen möchten.
Tags und Links sql-server-2008 entity-framework-4