Das Mysterium der GUIDs (Global Unique Identifier)

Eine GUID ist, wie der Name schon sagt, eine global eindeutige ID

Über das aktuelle Microsoft .Net framework kann man eine solche GUID über die Funktion

System.Guid.NewGuid

generieren.

Es ist ziemlich sicher, dass diese Id in diesem Universum eindeutig ist und bleibt. "Ziemlich" sicher...

Das "ziemlich" hängt von einigen kriterien ab

• 1. Davon wie lange man mit dieser funktion guids generiert, ohne den algorithmus bzw. die länge der generierten id zu ändern
• 2. Davon, ob der rechner auf dem die guid erzeugt wurde, über eine netzwerkkennung verfügt (das wird wohl auch so bleiben, da es die sicherste möglichkeit ist, die eindeutigkeit in einem verteilten system sicherzustellen, solange man nicht auf die idee kommt, die eindeutigkeit der netzwerkadresse aufzuheben und durch verschachtelte adressierung abzusichern; ich meine aber, dass das nicht gemacht wird; müsste der werte leser ggf. selbst raussuchen)
• 3. Davon, welche Maßnahmen man in der Zukunft ergreift, um sicherzustellen, dass guids weiter eindeutig bleiben.(ich hab für den mac-algorithmus 6000 Jahre im Kopf) Microsoft muss irgendwann mal vielleicht ein update für 256bit guids rausbringen (aktuell 128 bit)und man muss einen neuen netzwerkstandard rausbringen und einen zugehörigen generator schreiben. Für ipv6 hab ich im kopf dass du soviele adressen pro qubikzentimeter nutzbarer erdoberfläche vergeben kannst, dass du dir erst wieder gedanken machen brauchst, wenn die welt von kleinen nano-robotern übernommen worden ist.

Es gibt verschiedene Algorithmen zur berechnung einer guid, eine versionskennung des algorithmus ist in der GUID mit eingerechnet sodass die eindeutigkeit der GUID auch zwischen verschiedenen Algorithmen sichergestellt ist.

Irgendwo gibts wohl eine Organistation, die dir eine id vergibt, wenn du deinen eigenen algorithmus schreiben willst, aber das ist wohl eher ne kleine klitsche als eine organisation, wenn sie sonst nix machen, ausser versionskennungen für guid-generatoren zu vergeben.

Der (historisch erste?) Algorithmus verwendet die MAC-Adresse der Netzwerkkarte zur Berechnung. D.h. dass - sofern der Rechner auf dem die GUId berechnet wurde eine netzwerkkarte besitzt, ist die ID "eindeutig". Besitzt der Rechner keine Netztwerkkarte kann es vorkommen, dass er eíne GUID generiert, die schoneinmal geniert wurde (meiner Vermutung nach wird das dann aber wohl eine id sein, die auch von einem rechner ohne nw-karte berechnet wurde, damit bleibt das problem eingekreist)

Wie die anderen Algorithmen funktionieren weiss ich nicht; aber ich vermute, sie werden andere netzwerkkennungen (=>ipv6) verwenden oder als ausweichalgorithmus dienen und die guid zeit und standortabhängig berechnen was natürlich durch falschkonfiguration der systemzeit/ländereinstellungen entsprechend unsicher ist.

Es herrscht ziemlich viel allgemeine Verwirrung darüber, ob und wie lange eine guid eindeutig ist. (vor allem weil sich keiner hinsetzt und mal alles durchrechnet)

Da ist aber noch lange hin.

Aber was passiert wenn, doch mal eine doppelte rauspurzelt?

Eine doppelt generierte Guid kann zu verwechslungen, zu überschreiben von daten oder im blödesten fall zum datenverlust führen. Es gibt aber auch eine Möglichkeit diesen Fehler zu erkennen und zu behandeln:

Begegnen kann man dem damit, dass die datenschicht die eindeutigkeit von ids innerhalb des dokuments sicherstellt [1] und dass der client der datenschicht neu-anlagen explizit als solche ausweist.

guids werden nur bei neuanlage von objekte generiert. falls die guid schon existiert kommt es zu einem fehler 'der datensatz kann nicht hinzugefügt werden, weil ein objekt mit dieser id existiert bereits'. falls das programm nicht darauf reagiert (und das wird es kaum) gehen dem benutzer seine eben erfassten daten verloren, aber das gesamt system bleibt - sofern die transaktionen korrekt gesetzt sind - davon unbeeinträchtigt.

[1] in einer datenbank anwendung ist das der fall, da du im normalfall eindeutige rowids verwendest. wie ms-project ggf. bei neuanlage eines profils auf ein schon vorhandenes profil reagiert wissen nur die entwickler von project.

Fazit:

• 1. Extrem geringes Risiko, dass eine doppelt generierte guid sich auswirkt.
• 2. In grossen db anwendungen kommen eh nur clients mit netzwerk-karte an datenbanken ran, sodass die wahrscheinlichkeit einer doppelten guid ein weiteres riesen stück sinkt.
• 3. In Datenbankanwendungen sicherstellen, dass
• 3.1 die datenschicht eindeutigkeit von row ids sicherstellt
• 3.2 dass ein Insert ein Insert bleibt und ein Update ein Update. Wenn du natürlich eine SQL-StoredProcedure auf dem datenbankserver programmierst, die sagt If Exists Then Update Else Insert dann kann verlierst du diesen schutz und es kann passieren, dass der karlheinz auberle, der 3 schrauben bestellt hat, eine rechnung über 2.5 mio euro bekommt und sich beim daimler jemand saumäßig über sein budget freut. (das seines bleiben wird) Aber dass dir das passiert - da wirste eher in einer woche 20 mal vom blitz erschlagen, überlebst und hast den tag drauf nen 6er im lotto. (den gewinn bekommt aber jemand anders, weil in der lotto zentrale auch eine doppelte guid erzeugt wurde)

Weiteres:

• Durch die Verwendung von GUIDs auf Datenbankservern kommt es zu unperformanten Indizierungsverhaltung des Datenbankservers. Der aktuelle Microsoft-SQL-Server stellt daher eine eigenen Funktion zur generierung GUIDs, die innerhalb einer Tabelle sicherstellt, dass generierten GUIDS aufsteigend sind, was die Effizienz der Indizierung wieder herstellt.
• So wie ich das mitbekommen habe (werd ich noch überprüfen/durch featureunterstützung untermauern) verwendet man in aktuellen datenbank-servern guids als rowid. Das erleichtert die implementierung auf dem client ungemein, da ein client, wenn er einen datensatz anlegt, ansonsten den vom server vergebenen autowert vom db-server zurückbekommen muss, um mit dem objekt weiterarbeiten zu können. die an dieser stelle verwendeten sql-statements sind wahrscheinlich kritisch bzgl. portierbarkeit. Ich bin neulich darauf gestossen, dass das Microsoft Entity Framework (Ein ORM-Tool) anscheinend Auto-Werte gar nicht unterstützt.
• Die Generierung von GUIDS wird von vielen anderen Betriebssystem unterstützt. Bei Portierung von GUIDS muss man auf identische spezifikationen des algorithmus achten. Außerdem muss die byte-order verglichen werden, in der die guid aus-/ bzw. eingegeben wird. Diese ist nämlich nicht immer gleich. Durch verwechslung der Byte-Order kann es ebenfalls zu vermeintlich doppelt generierten guids kommen.