Ich habe die Verwendung von GUIDs als Primärschlüssel in Datenbanken untersucht. Bis jetzt scheinen die Profis die Nachteile zu überwiegen. Ich sehe jedoch einen Punkt, wo GUIDs möglicherweise nicht das sind, was ich will.
In meiner Anwendung sollten Benutzer in der Lage sein, Objekte basierend auf einer benutzerfreundlichen ID zu identifizieren. Wenn sie beispielsweise ein bestimmtes Produkt erhalten möchten, ohne den vollständigen Namen einzugeben, können sie die Produkt-ID verwenden. GUIDs sind für so etwas nicht leicht zu merken.
Die Lösung, an die ich gedacht habe, ist die Verwendung einer GUID und einer automatisch inkrementierenden Ganzzahl. Die GUID wäre der Primärschlüssel der Zeile, während die automatisch inkrementierende Ganzzahl ein Index wäre, der von den Filterfunktionen der Anwendung verwendet wird. Alle SQL SELECT-, UPDATE-, DELETE-Anweisungen würden jedoch die GUID verwenden.
Der Hauptgrund, warum ich GUIDs verwenden möchte, ist die Vermeidung von Konflikten beim Zusammenführen zweier Datenbanken. Wenn Datenbank # 1 und Datenbank # 2 beide ein Produkt # 2 haben, müsste das Importeurscript die ID und alle darauf bezogenen Fremdschlüssel ändern. Mit GUIDs muss ich nur die benutzerfreundliche ID in der Tabelle selbst ändern, während Fremdschlüssel die GUID für jeden importierten Datensatz verwenden und daher ohne Änderung funktionieren.
Meine Frage ist also: Gibt es irgendwelche größeren Probleme (abgesehen von der Größe des GUID-Feldes und der einfachen Seitenfragmentierung) mit einem automatisch inkrementierenden ganzzahligen Index und einem GUID-Primärschlüssel?
Ich verwende immer Ersatz-Primärschlüssel in meiner Datenbank. Das heißt: Diese Primärschlüssel haben keine tatsächliche Bedeutung in der Problemdomäne, und daher sind diese Primärschlüssel niemals Benutzern zugänglich. (Wenn dieser Ersatz-Primärschlüssel vom Typ GUID oder einer Identität ist, ist es mir egal; das hängt von den Anforderungen ab).
Wenn Sie sagen, dass Benutzer Objekte basierend auf einer benutzerfreundlichen ID identifizieren können, dann denke ich, dass diese benutzerfreundliche ID ein Wert ist, der zu Ihrer "Problemdomäne" gehört. Das bedeutet, dass diese ID in der Tat ein Attribut in Ihrer Tabelle sein sollte, aber nicht als Primärschlüssel in Ihrer Tabelle verwendet werden sollte.
Dies ermöglicht Ihnen auch, den Wert einer solchen benutzerfreundlichen ID zu ändern (falls dies erforderlich sein sollte), ohne dass Sie sich Sorgen darüber machen müssen, auch zugehörige Fremdschlüssel zu ändern.
"Warum sollten Benutzer in der Lage sein, Objekte anhand einer benutzerfreundlichen ID zu identifizieren"?
Meiner Meinung nach sollten Ihre Benutzer Datensätze mithilfe von Codes erfassen.
Nehmen wir an, Ihre Datenbank enthält Produkte (wie Sie es in Frage erwähnten). Wäre es nicht besser, wenn sie Codes hätten, um Produkte darzustellen, die die Benutzer eingeben könnten.
Sagen wir, Sie haben Tische und Stühle, als Benutzer würde ich lieber tbl und chr als 1 und 2 verwenden, um zu identifizieren, worüber ich spreche.
In MySQL müssen Sie Ihre numerische ID als PRIMARY KEY festlegen, da AUTO_INCREMENT möglicherweise nur die PRIMARY KEY ist, also auch NOT NULL .
Sie können immer noch UNIQUE INDEX in Ihrer GUID -Spalte definieren und sie überall verwenden, obwohl eine InnoDB -Tabelle in der numerischen id , nicht in GUID geclustert wird.
Es gibt eine Denkschule, die besagt, dass Sie Ihre Ersatz-IDs niemals der Außenwelt aussetzen sollten. Sie würden also sagen, wenn Sie eine Geschäfts-ID möchten, sollten Sie etwas anderes dafür verwenden.
In diesem Wikipedia-Artikel heißt es beispielsweise:
Dissoziation
Die Werte der generierten Ersatzschlüssel - weil sie erzeugt und willkürlich sind - haben keine Beziehung zu die reale Bedeutung der Daten in einer Reihe gehalten. Bei der Inspektion eines anderen Zeile, die einen Fremdschlüsselverweis enthält ein Ersatzschlüssel, ist es nicht möglich Erarbeiten Sie die Bedeutung des Haltens diese Referenz einfach durch Betrachten die Daten in der Zeile selbst. Eine Schicht ist zu dieser Indirektion für jeden hinzugefügt Fremdschlüssel beitreten das muss man navigieren, während Sie versuchen zu machen Sinn eines Datenelements. Dies kann auch Auditing schwieriger machen, als falsche Daten sind nicht offensichtlich Inspektion.
Ersatzschlüssel sind auch nicht natürlich für Daten, die exportiert und freigegeben werden. Eine besondere Schwierigkeit ist, dass zwei Instanzen eines Schemas können Datensätze speichern was logisch dasselbe bedeutet (Das ist - sie sind die gleichen in a Geschäftssinn), aber die eine haben verschiedene Schlüssel aufgrund der Geschichte von wie die Schlüssel zugewiesen wurden. Ein Umgang damit ist zu die Regel übernehmen, die Ersatzschlüssel sind nie exportiert oder importiert: sie sind nie außerhalb der Datenbank ausgesetzt außer als vorübergehende Daten (die meisten offensichtlich, beim Ausführen von Anwendungen die eine "Live" - Verbindung zum Datenbank).
Um genauer auf Ihre Frage einzugehen, gibt es andere Probleme mit der Verwendung von GUIDs als Primärschlüssel in Datenbanken:
Das Problem liegt nicht so sehr in der Verwendung einer GUID als Primärschlüssel, sondern in der Verwendung einer nicht sequentiellen GUID als gruppierten Index für eine Tabelle.
Hier können Sie entweder andere Felder als gruppierten Index verwenden oder eine sequenzielle GUID verwenden, um diese Fragmentierung zu vermeiden.
Tags und Links sql-server database guid indexing primary-key