vielleicht schaff ich es ja nie.. also klartext.. ich habe kein problem ;)
> Welcher zufall? > Vieles an der guid-berechnung ist nicht zuf�llig. > Die MAC adresse ist mit drin, d.h. es kann schon mal nur innerhalb des > selben rechners die gleiche GUID erzeugt werden. > Das Datum ist auch mit drin, d.h. da das Jahr vierstellig ist kann es im > prinzip nur alle 10000 Jahre die gleiche GUID erzeugt werden(achtung: > das heisst nicht, dass es auch passiert)... Abgesehen davon das es dann > zu anderen Problemen mit dem Datum kommt... die mac-adresse ist zwar drin, aber nicht als "klartext".. sie wird hin und hergewuchtet und zum schluss hast du eine zahlenkolonne, die nichts mehr mit deiner macid zu tun hat.. genauso bei dem datum. und genau da kommt dann der zufall mit ins spiel. guids k�nnen somit wohl auf unterschiedlichen rechnern gleich sein (ist sogar wahrscheinlicher) > > auch hier vergisst du eine komponente.. .nat�rlich will ich > > was eindeutiges.. angenommen du programmierst ein kl. > > steuerelement. und ich auch.. wir beide haben nun -der zufall > > wollte es so*g*- die gleiche guid und den gleichen kunden. > > was passiert also, wenn unser beider kunde unsere beiden > > komponenten installiert.. auf einem rechner haben guids > > nunmal eindeutig zu sein, und diese werden auf deinem system > > bestimmt, nicht erst beim kunden.. > > Wir waren eigentlich bei Datenbanken... Und da ist es egal, ob ein Kunde > zwei DBs hat, die von verschiedenen Applikationen verwendet werden und > aber die gleichen GUIDs enthalten.... Was ich aber trotzdem f�r > eigentlich ausgeschlossen halte... komm,... jetzt aber kein r�ckzieher.. es stand die frage im raum, ob guids 100%ig eindeutig sind.. (ich bin nun mal ein "griffelspitzer", wie man im schwabenl�ndle so sch�n sagt) ;) > > ich komme nicht darauf, dass eine "einfache" multiplikation > > gemacht wird..so wollte ichs nicht darstellen.(wie kommst du > > da drauf*g*) aber du wirst mir doch recht geben, dass 16bytes > > begrenzt sind.. oder? wenn du jetzt sagst,.. "dass reicht > > doch l�nger als es das universum gibt", dann erinnere ich > > dich gerne an ein "ph�nomen" namens y2k-bug .. 2stellige > > jahresangaben reichen ja auch l�nger, als es computer in > > dieser form geben wird, war bestimmt eine denkansatz(und > > zudem spielte eiserne sparsamkeit an jedem bit eine sehr > > gro�e rolle).. also ewig... trotzdem, oder gerade deswegen > > geb ich dir aber auch vollkommen recht. es reicht ewig... nur > > damit ists noch lange nicht eindeutig. (mehr hab ich nicht, > > und mehr wollte ich auch gar nicht darlegen) > > > > Die Berechnung sollte zeigen wie gross eigentlich der GUID-Raum ist... > Eindeutigkeit: siehe Zuf�lligkeit oben. > Den y2k-Bug kann ich nicht als Argument z�hlen, da es nichts zur Sache tut. der y2k-bug ist kein argument, nur ein beispiel (es kommt immer anders als man denkt..) > > und solange ich etwas "aus-/berechne", solange besteht eine > > m�glichkeit durch unterschiedliche rechenwege zum gleichen > > ergebnis zu kommen.. die macid und die uhrzeit und die > > zufallbits werden nicht aneinandergeh�ngt, da dadurch > > theoretisch (sp�testens im jahr 10000) eine verl�ngerte guid > > zum tragen kommen w�rde.. imho ist es sogar so stark > > Nein, dann wird es ein y10k-Bug geben... Aktuelle systeme k�nnen kein yahr 10000 >verarbeiten... > D.h. GUIDs in dieser Form, bzw. mit aktuellen Algorithmen wird man > sowieso nicht f�r ewig erzeugen k�nnen... stimmt auch wieder.. aber einmal ein "argument" in den wind schlagen und dann selbst verwenden is unfair;) > > verwurschtelt und durch zufallbits verdreht, dass man > > nichtmal zur�ckrechnen kann, wann die guid erstellt wurde. > > (ich glaub das mal gelesen zu haben, bin aber nicht ganz sicher) > > Das heisst aber nichts... > Wenn ich mit nem einfachen schl�ssel die GUID XORe, dann kannst Du auch > nicht mehr auf die GUID zur�ckrechnen... Das sagt nichts �ber die > Qualit�t der Ausnutzung des GUID-Raumes aus... ok.. dann mit xor.. da wird die wahrscheinlichkeit noch h�her gleiche zahlen zu bekommen ;) 24 xor 28 = 4 7 xor 3 = 4 11 xor 15 = 4 wieder nur ein kleines beispiel... nat�rlich wird die guid anders, und vor allem weitreichend bedachter berechnet > > > > nochmal. ich halte die guid f�r eindeutig genug. aber die > > aussage, dass diese 100%ig und immer und ewig eindeutig ist, > > ist schlicht und wenig ergreifend einfach falsch. sowas muss > > man auch gar nicht verbissen sehen, wenn man bedenkt, dass > > selbst 2 gleiche guids erst dann problematisch werden > > k�nnen(nicht m�ssen), wenn diese auf einem rechner vorhanden > > sind.. nichtmal dass reicht aus.. es m�sste sogar in der > > gleichen tabelle oder �hnlichem (zb registry) gespeichert > > sein, um endlich probleme verursachen zu k�nnen(auch dann > > ists nicht immer schlimm). > > > > Ich glaube das eigentliche Problem, das du hast ist, das du denkst: > GUID ist nicht unendlich gross, sondern nur 128bit, also kann es nicht > eindeutig sein... das war eine aussage.. richtig.. ein problem hab ich (wie im einleitenden satz gesagt) nicht. > 1. Anhand meiner Berechnung hast Du gesehen, dass es genug GUIDs gibt, > d.h. das erste Problem ist gel�st... naja..wo wir wieder beim berechnen und nicht beim "zusammenstellen" der guid w�ren. > 2.Problem: Wird auch keine GUID zweimal erzeugt? > L�sung: > - GUID enth�lt MAC. MAC ist eindeutig f�r einen Rechner/Netzwerkkarte > -> GUID-Dubletten k�nnen wenn �berhaupt nur auf dem selben Rechner > erzeugt werden. > - GUID enth�lt die aktuelle Zeit. > -> GUID-Dubletten k�nnen wenn �berhaupt nur zur selben Zeit erzeugt > werden... > - GUID enth�lt Zufall(und noch einige Komponenten) > -> GUID-Dubletten k�nnen wenn �berhaupt nur erzeugt werden, wenn der > Zufallsgenerator das selbe ausspuckt... punkt 1 und 2 ist wiederlegbar,.. punkt 3 geh�rt da nur zur h�lfte rein > Zusammengenommem kann gesagt werden das in den n�chsten paar tausend > jahren bestimmt keine einzige GUID mehrfach erzeugt wird... ich glaube (!!) mich zu erinnern, dass es irgendeine uni in wei�dergeierwoamiland mal versuch und auch geschafft hat. da ich dies nur glaube, gelesen zu haben, ists aber zurecht vollkommen irrelevant(wollts nur mal in den raum schmei�en).. und wer wei�, was f�r rechneranlagen da rumstanden. > Also eine Periode, die um einiges gr�sser ist als 30Jahre... > > Bei der Geschwindigkeit mit der heutige Entwicklungen > passieren bin ich mir sicher, das wir in 300 Jahren keine Applikation von heute mehr > laufen haben, auch wenn jetzt das y2k-Argument wieder kommt.... dieses argument kommt nicht (aus dem einfachen grund: du hast es ja schon hingeschrieben) > > nevermind .. wolfgang ;) > Selber nevermind... Claudius ;-) hmm.. was soll ich da noch schreiben... "mehr nevermind" ich glaub, wenn �berhaupt, dann sollten wir im kaffehaus weitermachen.. ansonsten wird noch jemand b�se. wolfgang ;) http://www.vbwelt.de/ | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
