Warum nicht immer GUIDs anstelle von Ganzzahl-IDs verwenden?

Ganzzahlen sind viel schneller, zum Beispiel. Dies ist besonders wichtig im Umgang mit Millionen von Zeilen.

Für zwei nehmen GUIDs mehr Platz in Anspruch als Ganzzahlen. Wiederum sehr wichtig im Umgang mit Millionen von Zeilen.

Bei dreien haben GUIDs manchmal unterschiedliche Formate, die in Anwendungen usw. einen Schluckauf verursachen können. Eine Ganzzahl ist eine Ganzzahl, durch und durch.

Ein genauerer Blick findet sich hier und auf Jeffs Blog .

GUIDs sind großartig aus der Perspektive eines Programmierers - sie sind garantiert (fast) einzigartig, also warum nicht überall verwenden, richtig?

Wenn Sie es aus DBA-Sicht und aus Datenbanksicht betrachten, müssen Sie zumindest für SQL Server einige Dinge beachten:

• GUIDs als Primärschlüssel (der für die eindeutige Identifizierung einer einzelnen Zeile in Ihrer Tabelle verantwortlich ist) könnten in Ordnung sein - schließlich sind sie eindeutig, oder?
• SQL Server hat jedoch auch das Konzept des Clustering-Schlüssels, der die Daten physisch in Ihrer Tabelle anordnet; Wenn Sie nichts darüber wissen und nichts explizit machen, wird Ihr Primärschlüssel Ihr Clustering-Schlüssel.

Kimberly Tripp - weltberühmter Experte für Indizierung und Leistung von SQL Server - hat sehr viele Blogposts darüber geschrieben, warum eine GUID als Clustering-Schlüssel eine wirklich schlechte Idee ist - sehen Sie sich ihre Blog auf Indizes .

Ihre Best Practices für einen Clustering-Schlüssel sind vor allem:

• eng
• statisch
• einzigartig
• immer größer

GUIDs sind normalerweise statisch und einzigartig - aber sie sind weder schmal (16 Byte vs. 4 Byte für einen INT) noch werden sie immer größer. Aufgrund ihrer Natur sind sie einzigartig und (pseudo-) zufällig.

Der enge Teil ist wichtig, weil der Clusterschlüssel zu jeder einzelnen Indexseite für jeden nicht gruppierten Index in Ihrer Tabelle hinzugefügt wird - und wenn Sie einige davon und einige Millionen Zeilen in Ihrer Tabelle haben Dies bedeutet eine enorme Verschwendung von Speicherplatz - nicht nur auf Ihrer Festplatte, sondern auch in Ihrem SQL Server-RAM.

Der ständig wachsende Teil ist unwichtig, weil die Zufälligkeit der GUIDs eine starke Fragmentierung in Ihren Indizes verursacht, was sich negativ auf Ihre Performance auswirkt. Selbst die newsequentialid() von SQL Server 2005 und höher erzeugen nicht wirklich sequentielle GUIDs - sie sind für eine Weile sequenziell und dann gibt es wieder einen Sprung, der Fragmentierung verursacht (weniger als total zufällige GUIDs, aber immer noch).

Alles in allem, wenn Sie wirklich an Ihrer SQL Server-Leistung interessiert sind, Verwenden von GUIDs als Clustering-Schlüssel ist eine wirklich schlechte Idee - verwenden Sie stattdessen INT IDENTITY (), möglicherweise mit einer GUID als primären (nicht geclusterten) Schlüssel, wenn Sie wirklich haben zu.

Marc

1. GUIDs sind viermal größer als ein int und doppelt so groß wie ein bigint.

2. GUIDs sind wirklich schwierig zu betrachten, wenn Sie versuchen, Tabellen zu behandeln.

GUIDs können die Generierung von Schlüsseln im Voraus vereinfachen oder Schlüssel offline oder in einem Cluster ohne Kollisionsgefahr generieren. Es kann auch einen leichten Sicherheitsvorteil geben, da alle Schlüssel nicht zu erkennen sind.

Der Nachteil ist, dass es schwerer zu lesen und zu tippen ist. An vielen Ihrer Tische können Sie später erkennen, dass Sie zurückgehen und trotzdem menschenfreundliche Schlüssel generieren müssen. Sie werden Ihre Datensätze auch gleichmäßig in einer Tabelle verteilen, wodurch es möglicherweise langsamer wird, mehrere Datensätze abzufragen, die ungefähr zur selben Zeit eingefügt wurden, als wenn Sie einen automatischen Schlüssel haben, bei dem Ihre Datensätze in der Reihenfolge der Zeit eingefügt werden.

Kimberly L. Tripp: GUIDs als PRIMÄRSCHLÜSSEL und / oder den Clustering-Schlüssel

Haben Sie die verwandten Links auf der rechten Seite gelesen?

GUIDs sind groß und langsam im Vergleich zu Ints - also verwenden Sie sie, wenn sie benötigt werden, vermeiden Sie sie, wenn sie NICHT benötigt werden, so einfach ist das!

Diese Antwort schließt NICHT die Idee aus, INTs als Primärschlüssel zu verwenden. Es ist hauptsächlich dazu gedacht, darauf hinzuweisen, WENN eine GUID nützlich ist.

HIER IST EIN GROSSER (KURZER) ARTIKEL:
Ссылка

Erklärt ...
Ich verwende GUIDs für jeden (gemeinsamen) DB-Entitätstyp, der möglicherweise exportiert oder mit einer anderen DB-Instanz geteilt werden muss. Auf diese Weise habe ich einen DNA-Marker (d. H. Die GUID), der verwendet werden kann, um zwischen "ähnlichen" Objekten desselben Entity-Typs zu unterscheiden.

Nehmen wir zum Beispiel an, dass zwei Datenbankinstanzen eine Tabelle namens PROJECT haben. Wenn die beiden Projekte den gleichen Namen oder die gleiche Nummer haben, ist es schwer zu unterscheiden, welches das ist. Durch die Verwendung von GUIDs können Sie jedoch leicht zwischen zwei Projekten unterscheiden und woher sie kommen ... selbst wenn sie viele ähnliche Werte haben. Das scheint unmöglich ... aber tatsächlich kann und passiert.

Der größte Leistungseinbruch, den Sie bei GUIDs als primären / gruppierten Schlüssel sehen, ist das Einfügen von Datensätzen in große Tabellen. Das erneute Indizieren kann eine schwere Aufgabe sein, da Ihr Schlüssel irgendwo in der Mitte liegt.

Die Verwendung von GUIDs als Primärschlüssel führt schließlich zum Absturz Ihrer Datenbank, da das Laufwerk zu fragmentiert wird. Dies ist ein Zustand, der als Thrashing bekannt ist.