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

StackOverflow https://stackoverflow.com/questions/45399

  •  09-06-2019
  •  | 
  •  

Frage

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 vorhanden gewesen wären GUID / UUID Werte.Ich habe ein paar Mal darüber nachgedacht, diesen Weg einzuschlagen, aber es gibt immer ein wenig Unsicherheit, insbesondere in Bezug auf die Leistung und nicht über das Telefon vorlesbare URLs.

Hat jemand intensiv mit GUIDs in einer Datenbank gearbeitet?Welche Vorteile hätte ich, wenn ich so vorgehen würde, und was sind die wahrscheinlichen Fallstricke?

War es hilfreich?

Lösung

Vorteile:

  • Kann sie offline generieren.
  • Macht die Replikation trivial (im Gegensatz zu ints, was es WIRKLICH schwierig macht)
  • ORMs mögen sie normalerweise
  • Einzigartig für alle Anwendungen.Wir können also die PKs aus unserem CMS (Guid) in unserer App (auch Guid) verwenden und wissen, dass es NIEMALS zu einem Konflikt kommen wird.

Nachteile:

  • Größerer Platzbedarf, aber Platz ist günstig(er)
  • Es ist nicht möglich, nach ID zu bestellen, um die Einfügungsreihenfolge zu erhalten.
  • Kann in einer URL hässlich aussehen, aber was machst du wirklich, wenn du einen ECHTEN DB-Schlüssel in eine URL einfügst?
  • Das manuelle Debuggen ist schwieriger durchzuführen, aber nicht so schwer.

Persönlich verwende ich sie für die meisten PKs in jedem System mit anständiger Größe, aber ich wurde auf einem System „trainiert“, das überall repliziert wurde, also MUSSTEN wir sie haben.YMMV.

Ich halte die Sache mit den doppelten Daten für Quatsch – man kann doppelte Daten bekommen, egal wie man es macht.Wo immer ich gearbeitet habe, sind Ersatzschlüssel normalerweise verpönt.Wir verwenden jedoch das WordPress-ähnliche System:

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

AKTUALISIEREN:Deshalb erhält dieser Punkt häufig +1, und ich dachte, ich sollte auf einen großen Nachteil von GUID-PKs hinweisen:Clustered-Indizes.

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

Wenn Sie also Einfügeleistung benötigen, verwenden Sie möglicherweise eine automatische Ink-Integration (INT) und generieren Sie eine GUID, wenn Sie sie mit jemand anderem teilen möchten (d. h. sie einem Benutzer in einer URL anzeigen möchten).

Andere Tipps

@Matt Sheppard:

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

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

Als nächstes werden Sie aus irgendeinem Grund (der mir nicht einfällt) aufgefordert, der Kundentabelle eine GUID-Spalte hinzuzufügen und diese zum Primärschlüssel zu machen.Wenn die Spalte „Kundenidentifikator“ jetzt ohne Eindeutigkeitsgarantie bleibt, werden Sie in der gesamten Organisation künftig Ärger bekommen, da die GUIDs immer eindeutig sind.

Ein „Architekt“ könnte Ihnen sagen: „Oh, aber wir kümmern uns darum.“ real Kundeneindeutigkeitsbeschränkung in unserer App-Ebene!“Rechts.Die Mode in Bezug auf allgemeine 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 aktuelle Anwendung zu durchlaufen.== Ärger.(Aber zum Glück sind Sie und der „Architekt“ schon lange nicht mehr da, sodass Sie nicht da sein werden, um das Chaos zu beseitigen.) Mit anderen Worten:Behalten Sie offensichtliche Einschränkungen in der Datenbank bei (und auch in anderen Ebenen, wenn Sie Zeit haben).

Mit anderen Worten:Es kann gute Gründe geben, Tabellen GUID-Spalten hinzuzufügen, aber erliegen Sie bitte nicht der Versuchung, dadurch Ihre Ambitionen auf Konsistenz innerhalb der Tabelle zu schmälern real (==Nicht-GUID-)Informationen.

Die Hauptvorteile bestehen darin, dass Sie eindeutige IDs erstellen können, ohne eine Verbindung zur Datenbank herzustellen.Und IDs sind weltweit eindeutig, sodass Sie Daten aus verschiedenen Datenbanken problemlos kombinieren können.Das scheinen kleine Vorteile zu sein, haben mir aber in der Vergangenheit viel Arbeit erspart.

Die Hauptnachteile sind, dass etwas mehr Speicherplatz benötigt wird (auf modernen Systemen kein Problem) und dass die IDs nicht wirklich für Menschen lesbar sind.Dies kann beim Debuggen ein Problem sein.

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

Bearbeiten Ich habe meine beiden Antworten auf diese Frage zusammengeführt

@Matt Sheppard Ich denke, er meint, dass Sie Zeilen mit unterschiedlichen GUIDs als Primärschlüssel duplizieren können.Dies ist ein Problem bei jeder Art von Ersatzschlüsseln, nicht nur bei GUIDs.Und wie er sagte, lässt es sich leicht lösen, indem man sinnvolle eindeutige Einschränkungen zu Nicht-Schlüsselspalten hinzufügt.Die Alternative besteht darin, einen natürlichen Schlüssel zu verwenden, und das bringt echte Probleme mit sich.

GUIDs können Ihnen in Zukunft große Probleme bereiten, wenn sie als „Uniqifier“ verwendet werden und doppelte Daten in Ihre Tabellen gelangen lassen.Wenn Sie GUIDs verwenden möchten, denken Sie bitte darüber nach, weiterhin UNIQUE-Einschränkungen für andere Spalten beizubehalten.

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

Ein weiteres kleines Problem, das Sie bei der Verwendung von GUIDS als Primärschlüssel berücksichtigen sollten, wenn Sie diese Spalte auch als Clustered-Index verwenden (eine relativ gängige Praxis).Beim Einfügen werden Sie einen Treffer einstecken, weil eine Anleitung ohnehin nicht sequenziell beginnt und es daher beim Einfügen zu Seitenteilungen usw. kommt.Nur etwas, das Sie berücksichtigen sollten, wenn das System hohe IO-Werte haben wird ...

Primärschlüssel-IDs-versus-Guids

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

Mythen, GUID vs.Automatisches Inkrementieren (MySQL 5)

Das ist wirklich das, was Sie wollen.

UID-Profis

  • Eindeutig für jede Tabelle, jede Datenbank, jeden 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 IDs überall generieren, anstatt einen Roundtrip zur Datenbank durchführen zu müssen
  • Die meisten Replikationsszenarien erfordern ohnehin GUID-Spalten

GUID-Kons

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

Es gibt eine Sache, die nicht wirklich angesprochen wird, nämlich die Nutzung zufällig (UUIDv4) IDs als Primärschlüssel beeinträchtigen die Leistung des Primärschlüsselindex.Dies geschieht unabhängig davon, ob Ihre Tabelle um den Schlüssel gruppiert ist oder nicht.

RDBMs gewährleisten in der Regel die Eindeutigkeit der Primärschlüssel und gewährleisten die Suche anhand eines Schlüssels in einer Struktur namens BTree, einem Suchbaum mit einem großen Verzweigungsfaktor (ein binärer Suchbaum hat einen Verzweigungsfaktor von 2).Nun würde eine sequentielle Ganzzahl-ID dazu führen, dass die Einfügungen genau erfolgen eins Seite des Baumes, wobei die meisten Blattknoten unberührt bleiben.Das Hinzufügen zufälliger UUIDs führt dazu, dass die Einfügungen die Blattknoten im gesamten Index aufteilen.

Wenn es sich bei den gespeicherten Daten ebenfalls überwiegend um zeitliche Daten handelt, muss häufig auf die neuesten Daten zugegriffen und diese mit den aktuellsten verknüpft werden.Bei zufälligen UUIDs profitieren die Muster davon nicht 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-Indexseiten weniger RAM.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top