MSSQL GUID oder Windows GUID

[Captnemo]

Danke für all die Antworten. Letztlich habt ihr meine Vermutung bestätigt.

Ich hatte mal in irgendeinem Forum gelesen, dass jemand ein Problem mit einer doppelten GUID hatte. Welchen Hintergrund das hatte konnte ich da aber nicht herauslesen.
Deswegen kamen mir dann doch noch Zweifel.

Ich hätte gedacht, dass MS bei der GUID über SQL möglicherweise zusätzlich prüft, ob es die schon gibt. Aber gut, bei der Wahrscheinlichkeit ist das wohl nicht notwendig.

Da ein SQL-Server ja meist auf einem Windows-Server läuft, und dieser in der Regel selten neu gestartet wird (sollte ), ist die GUID-vergabe über diesen ja noch sicherer, wenn diese aus dem Zeitstempel erzeugt wird.

Letztlich werde ich dann aber doch die GUID-Erzeugung am Client machen, weil mir das völlig ausreicht.
Wie Bernhard es schon erwähnt hat, hatte ich auch schon mein Fallstricke mit AutoInc-Feldern, so dass ich diese nicht gerne verwende.

Dank an alle.

[Bernhard Geyer]

Zitat von Captnemo:

Ich hätte gedacht, dass MS bei der GUID über SQL möglicherweise zusätzlich prüft, ob es die schon gibt.

Spätestens beim INSERT bei einem PK-Feld wird es von der DB geprüft

[himitsu]

Zitat von Bernhard Geyer:

Spätestens beim INSERT bei einem PK-Feld wird es von der DB geprüft

Die Frage ist ja, ob man will, daß es dann knallt.
Ich fände es schöner, wenn durch soein automatisch berechnetes Feld nicht gleich das ganze Insert in nicht nachvollziehbarer Weise wegknallt.

[Furtbichler]

Die GUID ist ein weltweit eindeutiger Identifikator. Die Wahrscheinlichkeit, das zwei identische GUID in einem System existieren ist so gering, das sich niemand ersthaft mit diesem Problem beschäftigt. Wieso willst Du der erste sein?

[himitsu]

Aus Prinzip?

Sie ist statistisch "theoretisch" weltweit eindeutig. Sie aber nicht eineindeutig.

[WM_CLOSE]

Die doppelte GUID lässt sich recht einfach provozieren.
Wenn das dann einen Programmfehler verursacht, der Schaden verursacht,
kann man auch nicht sagen "Das war ja sowas von unwahrscheinlich, deshalb habe ich keine Fehlerbehandlung eingebaut".
Die GUID ist nunmal eine endliche Zahl und kann daher nicht ohne weiteres als "unique" bezeichnet werden. Eine Überprüfung ist immer unerlässlich!
(Wobei ich glaube dass SQL-Server eine solche Überprüfung schon eingebaut hat)

[Furtbichler]

Ich bin mir bewusst, das man eine eine Wahrscheinlichkeit (von Duplizität) von 1:3.4* 10^1038 ungleich 0 ist, aber die GUID wurde nun mal dafür entwickelt, das man sich nicht darum kümmern muss.

Theoretisch kann ich natürlich zwei identische GUID erzeugen, entweder mit Absicht (das soll uns aber hier nicht interessieren), oder, weil der GUID-Generierungsalgorithmus fehlerhaft, d.h. nicht dem Standard entspricht.

Wenn ich also eine GUID verwende, dann kann ich mich darauf verlassen, das sie eindeutig ist. Aber da jeder schon Pferde vor der Apotheke hat kotzen sehen, kann man das noch abfangen, wenn man denn nichts besseres zu tun hat. Aber -wie schon erwähnt-, Programmierer machen das eigentlich nicht.

Natürlich kann ich so programmieren, das z.B. vor jedem Dateizugriff geprüft wird, ob die Festplatte nicht zwischenzeitlich von Außerirdischen entwendet wurde, aber ich halte es da lieber so, das ich das System gegen die Wand fahren lasse (aka auf Exception reagieren). Ich bin nämlich der Ansicht, das die Wahrscheinlichkeit, das eine HD von Außerirdischen weggebeamt wird, in der o.g. Größenordnung liegt.

Bei einer Datenbank, für die die GUID ihrem Namen gerecht werden soll, wäre das ein unique Index auf der Spalte. Das aber nicht dafür, das ich wirklich die Hostenträger an den Gürtel tackere, sondern um deklarativ darauf hinzuweisen, das diese Spalte erstens zum Suchen geeignet und zweitens per definitionem eindeutig ist. Das mir das RDBMS nebenbei eine (hier eigentlich überflüssige) Prüfung einbaut, ist nett und nicht(!) performancefressend, da die Prüfung en passant beim Einfügen passiert. Also nehme ich das mit.

Allerdings ist die Verwendung einer GUID ein PK performancetechnisch nicht gerade erste Wahl. Ein PK wird i.A. als Clustered Index angelegt. Neue Einträge werden also nicht ans Ende des Index geschrieben, sondern irgendwo in die Mitte, was zu ziemlichen Umkopieroperationen (B-Bäume) führt. Aber darum geht es hier ja nicht.

Zitat von WM_CLOSE:

Wenn das dann einen Programmfehler verursacht, der Schaden verursacht,
kann man auch nicht sagen "Das war ja sowas von unwahrscheinlich, deshalb habe ich keine Fehlerbehandlung eingebaut".

Doch, denn Du kannst eh nicht alles abfangen, und viel (sehr! viel!) wahrscheinlicher sind doch andere Faux-Pas.

Da RAM-Fehler weitaus häufiger vorkommen, als doppelte GUID, müsstest Du mit deiner Logik dann ja prüfen, ob nach einer Zuweisung wirklich alles kopiert wurde? Halte ich für ziemlich anstrengend.