Vor- und Nachteile von GUID / UUID-Datenbankschlüsseln

Ich habe in der Vergangenheit an einer Reihe von Datenbanksystemen gearbeitet, bei denen das Verschieben von Einträgen zwischen Datenbanken viel einfacher gewesen wäre, wenn alle Datenbankschlüssel GUID / UUID- Werte gewesen wären . Ich habe ein paar Mal darüber nachgedacht, diesen Weg einzuschlagen, aber es gibt immer ein bisschen Unsicherheit, insbesondere in Bezug auf die Leistung und nicht über das Telefon auslesbare URLs.

Hat jemand ausgiebig mit GUIDs in einer Datenbank gearbeitet? Welche Vorteile hätte ich auf diese Weise und was sind die wahrscheinlichen Fallstricke?

Vorteile:

• Kann sie offline generieren.
• Macht die Replikation trivial (im Gegensatz zu Ints, was es WIRKLICH schwierig macht)
• ORMs mögen sie normalerweise
• Anwendungsübergreifend einzigartig. Wir können also die PKs aus unserem CMS (guid) in unserer App (auch guid) verwenden und wissen, dass wir NIEMALS einen Konflikt bekommen werden.

Nachteile:

• Größere Raumnutzung, aber Platz ist billig (äh)
• Ich kann nicht nach ID bestellen, um die Einfügereihenfolge zu erhalten.
• Kann in einer URL hässlich aussehen, aber wirklich, WTF, setzen Sie einen REAL DB-Schlüssel in eine URL!? (Dieser Punkt ist in den Kommentaren unten umstritten)
• Schwierigeres manuelles Debuggen, aber nicht so schwer.

Persönlich benutze ich sie für die meisten PKs in jedem System von anständiger Größe, aber ich wurde auf einem System "geschult", das überall repliziert wurde, also mussten wir sie haben. YMMV.

Ich denke, die Sache mit doppelten Daten ist Müll - Sie können doppelte Daten erhalten, wie auch immer Sie es tun. Ersatzschlüssel sind normalerweise verpönt, wo immer ich gearbeitet habe. Wir verwenden jedoch das WordPress-ähnliche System:

• eindeutige ID für die Zeile (GUID / was auch immer). Für den Benutzer niemals sichtbar.
• Die öffentliche ID wird EINMAL aus einem Feld generiert (z. B. der Titel - machen Sie ihn zum Titel des Artikels).

UPDATE: Also wird dieser viel + 1'ed, und ich dachte, ich sollte auf einen großen Nachteil von GUID PKs hinweisen: Clustered Indexes.

Wenn Sie viele Datensätze und einen Clustered-Index für eine GUID haben, wird Ihre Einfügeleistung SAUGEN, da Sie Einfügungen an zufälligen Stellen in der Liste der Elemente erhalten (das ist der Punkt), nicht am Ende (was schnell ist).

Wenn Sie also Leistung beim Einfügen benötigen, verwenden Sie möglicherweise eine INT mit automatischer Eingliederung und generieren Sie eine GUID, wenn Sie sie für andere Personen freigeben möchten (dh sie einem Benutzer in einer URL anzeigen möchten).

@ Matt Sheppard:

Angenommen, Sie haben eine Kundentabelle. Sicherlich möchten Sie nicht, dass ein Kunde mehr als einmal in der Tabelle vorhanden ist, oder es kommt zu großer Verwirrung in Ihren Verkaufs- und Logistikabteilungen (insbesondere, wenn die mehreren Zeilen über den Kunden unterschiedliche Informationen enthalten).

Sie haben also eine Kundenkennung, die den Kunden eindeutig identifiziert, und Sie stellen sicher, dass die Kennung dem Kunden bekannt ist (in Rechnungen), damit der Kunde und die Kundendienstmitarbeiter eine gemeinsame Referenz haben, falls sie kommunizieren müssen. Um sicherzustellen, dass keine doppelten Kundendatensätze vorhanden sind, fügen Sie der Tabelle eine Eindeutigkeitsbeschränkung hinzu, entweder über einen Primärschlüssel in der Kundenkennung oder über eine NOT NULL + UNIQUE-Einschränkung in der Spalte Kundenkennung.

Als nächstes werden Sie aus irgendeinem Grund (an den ich nicht denken kann) gebeten, der Kundentabelle eine GUID-Spalte hinzuzufügen und diese zum Primärschlüssel zu machen. Wenn die Spalte mit der Kundenkennung jetzt keine Eindeutigkeitsgarantie mehr enthält, fragen Sie nach zukünftigen Problemen im gesamten Unternehmen, da die GUIDs immer eindeutig sind.

Einiger „Architekt“ könnte man sagen , dass „oh, aber wir behandeln echte Kunden Einzigartigkeit Einschränkung in unserem App - Tiere!“. Richtig. Die Mode in Bezug auf diese universellen Programmiersprachen und (insbesondere) Middle-Tier-Frameworks ändert sich ständig und wird Ihre Datenbank im Allgemeinen nie überleben. Und es besteht eine sehr gute Chance, dass Sie irgendwann auf die Datenbank zugreifen müssen, ohne die vorliegende Anwendung durchzugehen. == Ärger. (Aber zum Glück sind Sie und der "Architekt" schon lange nicht mehr da, sodass Sie nicht da sind, um das Chaos zu beseitigen.) Mit anderen Worten: Behalten Sie offensichtliche Einschränkungen in der Datenbank bei (und in anderen Ebenen, falls vorhanden) die Zeit).

Mit anderen Worten: Es kann gute Gründe geben, GUID-Spalten zu Tabellen hinzuzufügen, aber bitte fallen Sie nicht in die Versuchung, Ihre Ambitionen auf Konsistenz innerhalb der realen (== Nicht-GUID-) Informationen zu verringern.

Warum erwähnt niemand die Leistung? Wenn Sie mehrere Joins haben, die alle auf diesen fiesen GUIDs basieren, wird die Leistung durch den Boden gehen, da gewesen :(

GUIDs können Ihnen in Zukunft große Probleme bereiten, wenn sie als "Uniqifiers" verwendet werden und doppelte Daten in Ihre Tabellen gelangen. Wenn Sie GUIDs verwenden möchten, sollten Sie die UNIQUE-Einschränkungen für andere Spalten beibehalten.

Die Hauptvorteile sind, dass Sie eindeutige IDs erstellen können, ohne eine Verbindung zur Datenbank herzustellen. Und IDs sind global einzigartig, sodass Sie Daten aus verschiedenen Datenbanken problemlos kombinieren können. Dies scheint ein kleiner Vorteil zu sein, hat mir aber in der Vergangenheit viel Arbeit erspart.

Die Hauptnachteile sind etwas mehr Speicherplatzbedarf (kein Problem bei modernen Systemen) und die IDs sind nicht wirklich lesbar. Dies kann beim Debuggen ein Problem sein.

Es gibt einige Leistungsprobleme wie die Indexfragmentierung. Aber diese sind leicht lösbar (Kammführungen von Jimmy Nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Bearbeiten hat meine beiden Antworten auf diese Frage zusammengeführt

@ Matt Sheppard Ich denke, er meint, dass Sie Zeilen mit verschiedenen GUIDs als Primärschlüssel duplizieren können. Dies ist ein Problem mit jeder Art von Ersatzschlüssel, nicht nur mit GUIDs. Und wie er sagte, ist es einfach zu lösen, indem nicht-Schlüsselspalten bedeutungsvolle eindeutige Einschränkungen hinzugefügt werden. Die Alternative ist die Verwendung eines natürlichen Schlüssels und diese haben echte Probleme.

Ein weiteres kleines Problem bei der Verwendung von GUIDS als Primärschlüssel, wenn Sie diese Spalte auch als Clustered-Index verwenden (eine relativ häufige Vorgehensweise). Sie werden einen Treffer beim Einfügen erzielen, da die Art der Guid ohnehin nicht sequentiell beginnt. Daher handelt es sich beim Einfügen um Seitenaufteilungen usw. Nur etwas zu beachten, wenn das System hohe E / A haben wird ...

Primärschlüssel-IDs versus Guids

Die Kosten für GUIDs als Primärschlüssel (SQL Server 2000)

Mythen, GUID vs. Autoincrement (MySQL 5)

Das ist wirklich was Sie wollen.

UID-Profis

• Einzigartig in jeder Tabelle, jeder Datenbank, jedem Server
• Ermöglicht das einfache Zusammenführen von Datensätzen aus verschiedenen Datenbanken
• Ermöglicht die einfache Verteilung von Datenbanken auf mehrere Server
• Sie können überall IDs generieren, anstatt einen Roundtrip zur Datenbank durchführen zu müssen
• Die meisten Replikationsszenarien erfordern ohnehin GUID-Spalten

GUID Cons

• Es ist satte viermal größer als der traditionelle 4-Byte-Indexwert; Dies kann schwerwiegende Auswirkungen auf die Leistung und den Speicher haben, wenn Sie nicht vorsichtig sind
• Umständliches Debuggen (wobei userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Die generierten GUIDs sollten teilweise sequentiell sein, um die beste Leistung zu erzielen (z. B. newsequentialid () unter SQL 2005) und um die Verwendung von Clustered-Indizes zu ermöglichen

Es gibt eine Sache, die nicht wirklich angesprochen wird, nämlich die Verwendung von zufälligen (UUIDv4) IDs als Primärschlüssel, die die Leistung des Primärschlüsselindex beeinträchtigen . Es wird passieren, ob Ihre Tabelle um den Schlüssel gruppiert ist oder nicht.

RDBMs stellen normalerweise die Eindeutigkeit der Primärschlüssel sicher und stellen die Suche nach einem Schlüssel in einer Struktur namens BTree sicher, bei der es sich um einen Suchbaum mit einem großen Verzweigungsfaktor handelt (ein binärer Suchbaum hat einen Verzweigungsfaktor von 2). Jetzt würde eine sequentielle Ganzzahl-ID dazu führen, dass die Einfügungen nur auf einer Seite des Baums auftreten und die meisten Blattknoten unberührt bleiben. Durch Hinzufügen zufälliger UUIDs werden die Einfügungen die Blattknoten im gesamten Index aufteilen.

Ebenso ist es häufig der Fall, dass auf die neuesten Daten zugegriffen und diese gegen die meisten verknüpft werden müssen, wenn die gespeicherten Daten größtenteils zeitlich begrenzt sind. Bei zufälligen UUIDs profitieren die Muster nicht davon und treffen mehr Indexzeilen, wodurch mehr Indexseiten im Speicher benötigt werden. Wenn bei sequentiellen IDs die neuesten Daten am meisten benötigt werden, benötigen die Hot-Index-Seiten weniger RAM.