UUID als Primärschlüssel in einer referenziellen Datenbank

E

enrem

Erfahrenes Mitglied
29
Hallo zusammen!

ich möchte evtl. die UUID als Primärschlüssel verwenden. Hat jemand Erfahrung damit? Ich bin hin und her gerissen wie ich meine Primärschlüssel nun aufbaue.

Konkret geht es um lokale SQLite-Datenbanken deren Daten später zusammengeführt werden sollen. Als Beispiel hätte ich da eine Kundentabelle mit einer Spalte idKunde und eine Rechnungstabelle mit der Spalte idRechnung. Die Rechnungstabelle besitzt ebenfalls eine Spalte idKunde da eine 1:N Beziehung von Kunde zur Rechnung besteht.

Diese id´s würde ich gerne mit UUID´s füllen.

String uniqueId = UUID.randomUUID().toString();

In diesem Beispiel wird eine zufällige UUID erzeugt. Wie kann ich eine Namens oder Zeitbasierte UUID erzeugen?

Würde mich über ein Feedback und eure Lösungsansätze freuen…
 
Zuletzt bearbeitet:
Hi.

ich habe schon verschiedene Varianten durch.
Gerne benutze ich konsekutive long ids, da man die besser von Hand verstehen und mappen kann während dem debuggen.
Das ist aber immer mit etwas Arbeit verbunden.
UUIDs sind natürlich super, weil sie unique sind, einfach zu generieren. Sie sind halt unhandlich.
Von zeitbasierten UUIDs würde ich die Finger lassen. Da hab ich schon extreme Probleme erlebt wenn die Zeit auf dem Gerät nicht stimmt, Zeitumstellung etc.

Wenn du mehrere Datenbanken später zusammen führen willst und die Datensätze ihren primary Key behalten sollen würde ich zu UUIDs tendieren. Dann hast du keine Probleme mit doppelten long/integer IDs.
 
Danke deek.

deek schrieb:
Gerne benutze ich konsekutive long ids,

Ja so ähnlich hatte ich das begonnen (Neuentwicklung). Bis ich auf die UUID´s gestoßen bin. Mein Ansatz war es zunächst über die 15 stellige IMEI zu lösen. Dabei wird immer nur eine Datenbank des jeweiligen Geräts synchronisiert. Die Datenbank bekommt den Namen der IMEI.

Beispiel Datenbankname "123456789012345.sqlite"

Spalte mit id

id
1
2
3

idKunde
"123456789012345_1"
"123456789012345_2"
"123456789012345_3"

Dabei wollte ich den Inhalt als String und nicht als long ablegen damit ich über den Unterstrich die IMEI herauslesen kann. Möchte da nicht mit festen Werten wie left(15) arbeiten weil ich damit rechne das die IMEI mal länger werden kann. Mann weis ja nie.

Eine virtuelle Spalte "QuelleIMEI" kann ich dann in etwa so generieren.

SELECT substr(idKunde,1,instr(idKunde,"_")-1) AS QuelleIMEI, * From Kunde

Der Zugriff am PC hält sich in grenzen. Ergebnis: 1 Mio. Zeilen in 403ms zurückgegeben.

Hab da noch 2 Fragen?

1) Spricht was dagegen die idKunde als String (Caracter) zu verwenden? Also so wie ich es begonnen habe?
2) Wenn du zu nicht zeitbasierte UUIDs neigst (das mit dem Zeitproblem da stimme ich dir zu) wie kann ich dann in Android eine Namensbasierte UUID erzeugen? Ich habe das mit den Knoten noch nicht so ganz verstanden.
 
Für mich spricht nichts dagegen idKunde als String zu repräsentieren. Musst du mit UUIDS ja auch machen.

Mit Name based hab ich auch noch nicht viel Erfahrung. Vielleicht hilft dir das hier: Guide to UUID in Java | Baeldung
Ich sehe aber keinen Vorteil gegenüber random.

Kleiner Hinweis noch: Denk dran, dass nicht jedes Gerät eine IMEI hat. Falls deine App auf Tablets ohne Mobilfunkmodul verwendet wird gibt es keine IMEI.
 
  • Danke
Reaktionen: enrem
Danke für den Hinweis mit der IMEI. Daran hatte ich tatsächlich nicht gedacht. Das wäre echt übel geworden. Ich glaube dann werde ich eine Lösung dazwischen nehmen.

Statt die IMEI verwende ich eine randomUUID. Die einzelnen ids wie idKunde oder idRechnung generierie ich wie schon angefangen über die laufende Nr plus UUID statt IMEI.

Damit benötige ich auch keine Telefonrechte.

Beispiel Datenbankname "123e4567-e89b-42d3-a456-556642440000.sqlite"

idKunde
"123e4567-e89b-42d3-a456-556642440000_1"
"123e4567-e89b-42d3-a456-556642440000_2"
"123e4567-e89b-42d3-a456-556642440000_3"

Nachmals besten Dank deek.
 

Ähnliche Themen

S
Antworten
33
Aufrufe
2.672
Sempervivum
S
Manny87
  • Manny87
Antworten
11
Aufrufe
166
swa00
swa00
R
  • raller
Antworten
15
Aufrufe
549
DOT2010
DOT2010
Zurück
Oben Unten