GUID bzw. UUID

[reibi]

Hallo

Ich benutze folgendes :

 System.out.println(UUID.randomUUID().toString());

um mir ne UUID zu generieren.

1.) Gibts ne Möglichkeit, die Striche wegzulassen? Das braucht nur Speicherplatz und der ist in meinem Fall knapp.
2.) In der Javadoc steht für die Methode "randomUUID" folgender Text :

Static factory to retrieve a type 4 (pseudo randomly generated) UUID.

Mich irritiert "pseudo randomly generated" kann da was unvorhergesehenes passieren? also weltweit? Vielleicht das ein anderer Compi genau die gleiche ID generiert, abhängig vom ramdom-Prozess? Also weil das da explizit steht.

gruss

 

[bygones]

da es keine wirklichen Zufallszahlen in der Computerwelt gibt heisst es immer "pseudo"...

 

[faetzminator]

Vielleicht das ein anderer Compi genau die gleiche ID generiert, abhängig vom ramdom-Prozess?

Natürlich, das kann immer und überall passieren. Nur ist die Chance bei grösseren IDs natürlich kleiner.

 

[maki]

1.) Gibts ne Möglichkeit, die Striche wegzulassen? Das braucht nur Speicherplatz und der ist in meinem Fall knapp.

Kannst dir das doch auch als 2 long Werte geben lassen (getLeastSignificantBits/getMosttSignificantBits), spart nochmals Platz.

Wozu brauchst du die GUID denn?
Hoffe nicht für ein ID Feld einer DB...

 

[reibi]

Hallo Maki

Ich brauchs für 2 Sachen. Einmal für den Inhalt eines Barcodes(deshalb der Platzmangel) und als zweites auch indirekt als DB-ID. sprich den Schlüssel.

Wieso hoffst Du das ich das nicht als DB-ID benutze? Sollte doch so eindeutig sein.
und:
das mit den 2 long werten. klar... aber ich brauch doch die String-Representation mit buchstaben und so.

Gruss ;-)

 

[maki]

Wieso hoffst Du das ich das nicht als DB-ID benutze? Sollte doch so eindeutig sein.

Eindeutig ja, aber
1. IDs niemals als String imho
2. Eine GUID ist echt ein Bremsfaktor wenn du manuell Daten in der DB überprüfen/ändern musst, schon mal ein SQL Statement geschrieben in dem mehrere GUIDs vorkamen? So etwas vergisst man nicht so schnell ist nämlich zum abgewöhnen

Würde mir da lieber ein natürliches eindeutiges Merkmal holen und IDs von der DB generieren lassen (SQL Integer).

 

[reibi]

Hallo Maki

Klar würd ich selber auch nich so machen...is aber abhängig von nem Fremdsystem welches das so verlangt. Ich als pseydo DB-Spezi ;-) mach das auch immer so, dass ich die ID von der DB selber erstellen lasse.

In meinem Fall ist das aber abhängig von nem nachläufigen prozess. Also das mit dem Barcode usw. Nach Deiner Variante müsste man zuerst den datensatz erstellen, dann der Prozess dann die Daten in den Datensatz schreiben. Also min 2 Interaktionen mit der DB ...

Unabhängig davon mach ich aber nicht das DB-Design; das ist abhängig vom Fremdsystem. leider ist das so.

zu 2.) Mit Bremsfaktor: Is klar, wenn man ein Statement mit mehreren Strings, vielleicht noch als Vergleich, macht. Wenn man aber Statements wie: "SELECT * FROM TAB where id=myUUID" ist oder "INSERT INTO TAB VALUES id=myUUID" benutzt ... isses dann auch spürbar langsamer(Beispielsweise bei 50mille Datensätzen) ??

Gruess ;-)

 

[FArt]

Es ist nicht immer möglich einen eindeutigen Schlüssel von der DB generieren zu lassen.
Was spricht gegen einen Schlüssel in Textform?
Habt ihr euch schon mal die Wahrscheinlichkeit vor Augen geführt, mit der die gleiche UUID noch einmal generiert wird? Das macht die Diskussion hier hinfällig.

Es bleibt nur eine Frage, und die muss der Threadstarter selber beantworten: wenn ich die Anzahl der Stellen reduziere oder die Wertigkeit einer Stelle, steigt die Wahrscheinlichkeit für doppelt generierte IDs. Wo liegt dein Grenzwert?

Wenn ich eine technische ID nach dem Gesichtspunkt generiere, dass ich damit per Hand ein SQL Statement klöppeln möchte, dann ist das ein suboptimales Kriterium.