[MySQL] Engine, GUIDs, Foreign Keys

[Eroli]

Hallo zusammen,

ich habe mir vorgenommen, das Datenbankdesign eines bestehenden Projektes zu erfrischen und wollte jetzt mehr mit Primary-/Foreign-Keys arbeiten (also auch mit INNER und OUTER JOINS etc).

Außerdem will ich auch Referenzen benutzen. Wenn ein Datensatz A also mit Datensatz B aus einer anderen Tabelle verknüpft ist, sollte B automatisch mitgelöscht werden, wenn ich A löschen will (nur so als Beispiel).

Insofern ich das richtig verstanden habe, beherrscht nur die InnoDB-Engine dies wirklich, oder?

Außerdem habe ich mich zwischenzeitlich sehr mit dem angenehmen Umgang mit GUIDs aus den MS SQL Server angefreundet und wollte die eigentlich nun auch mit MySQL benutzen, doch es gibt kein entsprechendes Feld dafür, richtig? Warum eigentlich nicht?!

Muss ich jetzt ein char(36)-Feld benutzen? Resultiert das nicht in erheblichen Performanceeinbußen?

Da ich mir schon vorgenommen habe, die Datenbank neu zu designen würde ich es schon begrüßen, wenn das System dadurch schneller arbeitet und nicht langsamer.

Sehe ich hier einen berechtigten Knackpunkt?

Ciao,
Eroli

 

[Biber2]

Moin Eroli,

noch zuviele Unklarheiten zur punktgenauen Beantwortung deiner Fragen..

Das Wichtigste:
Was ist deine Motivation für/dein vermeintlicher Bedarf an GUIDs/UUIDs?

Da kann es nur zwei akzeptable Begründungen geben:
a) Du bist gezwungen, aus einem Alt- oder Quellsystem vorhandene GUIDs zu übernehmen - z.B aus einem Kontext mit Replikation bei MSSQL.
b) Du musst eindeutig generierte PKs sicherstellen, weil deine Bierdeckelverwaltungs-Appz irgendwann bestimmt mehr als 30 Mio Datensätze haben wird ;-)

Wenn keiner dieser beiden Fälle vorliegt: lass es.

Erstens weil natürliche Schlüssel (meinetwegen auch zusammengesetzte wie "Kundennr, Auftragsnr, Auftragspos") immer ein saubereres DB-Design erzwingen als künstlich erzeugte IDs. Und es da schon wirklich echter Argumente bedarf, um stattdessen einen substitute key einzuführen.

Zweitens, weil bei GUIDs/UUID in mySQL (zumindest bei den Umsetzungen, die ich bislang miterleben durfte) eine zwar interessante, aber nicht sonderlich geniale Auslegung dieser xUID-Datentypen stattfand.
Wie auch von dir angedeutet, könnte man/frau ja so eine UID als CHAR(32) oder gar als VarChar(36) abbilden.. alles Quark
Eine xUID ist 128bit lang, also 16 Byte --> Binary(16)

Allerdings hättest du bei handelsüblichen xUIDs das Problem, dass die etwas zusammenbraten aus z.B. Timestamp, Username und Computername... in den am Haufigsten verwendeten xUID-Varianten ist der Computername am Ende der UUID als relativ langer "konstanter" Teil der Stringrepräsention. Wenn die GUID immer auf dem DB-Server erzeugt wird.
Nicht sonderlich geeignet für eine gleichmäßige Streuung der Indexeinträge und ein spürbarer Overhead bei Index-Reorganisation (bei Insert/Updates/Delete)
Da wiederum kannst du dich nur frühzeitig rausdrehen durch durch ein "Umsortieren" der xUID-Schlüssels (z.B. mit "REVERSE(UNHEX(REPLACE(UUID(),’-',”)))", wenn UUID eine xUID a la MS ist ... dann ist aber ein Teilziel, nämlich die "Gleichheit" der Schlüssel von Altsystem und mySQL-System auch wieder Geschichte.

Bevor ich hier (noch mehr) ins Schwafeln komme nochmal die Frage:
Was treibt dich zu dieser Idee mit GUIDs?

Grüße
Biber

 

[Eroli]

Hallo Biber,

vielen Dank für deine kompetente Antwort.

Das Wichtigste:
Was ist deine Motivation für/dein vermeintlicher Bedarf an GUIDs/UUIDs?

Nunja, ich lernte diese Technik eigentlich erst vor wenigen Monaten durch meinen Nebenjob kennen. Dort habe ich mittlerweile recht viel mit MS SQL Server zu tun und die dort eingesetzte Datenbankstruktur beruht auf PK und FK durch GUIDs realisiert.
Zuerst hatte ich zwar Schwierigkeiten mich damit anzufreunden (meine Hobbyprojekte bis dato verwendeten einfache selbst-inkrementierende Counter), doch mittlerweile gefällt mir das System sehr gut und ich denke, dass es einfach zu profesionellem Datenbankdesign dazugehört.

Außerdem habe ich mal gelesen, dass INT-Counter als PK ineffizient seien, da man unter Umständen z.B. erst 11 Stellen vergleichen muss(z.B.: 00000000001; 00000000002), bis man sicherstellen kann, ob diese Row der gesuchte Eintrag ist oder nicht. Dieses Problem hat man bei GUIDs ja nunmal nicht.

(Außerdem hasse ich die entstehenden Lücken in einer Tabelle, wenn man Datensätze, welche durch einen Counter indiziert werden, löscht.)

Ich will also eigentlich nur ein professionelles und performantes Datenbankdesign auf dem Stand der Zeit haben (Selbst wenn diese Datenbank wahrscheinlich nie 30 Millionen Datensätze fassen wird, sondern nur einige Tausend (nach einem Jahr Laufzeit sind es derzeit 2500)).

in den am Haufigsten verwendeten xUID-Varianten ist der Computername am Ende der UUID als relativ langer "konstanter" Teil der Stringrepräsention. Wenn die GUID immer auf dem DB-Server erzeugt wird.

Das ist doch positiv, oder nicht? Wenn der relativ konstante Teil erst am Ende kommt, kann man doch bestimmt bereits nach den ersten paar Vergleichen erkennen, ob das der gesuchte Eintrag ist, oder nicht. Oder habe ich hier einen Denkfehler?

Eine xUID ist 128bit lang, also 16 Byte --> Binary(16)

Du meinst VARBINARY(16)?

 

[dbwizard]

Moin Eroli,

Erstens weil natürliche Schlüssel (meinetwegen auch zusammengesetzte wie "Kundennr, Auftragsnr, Auftragspos") immer ein saubereres DB-Design erzwingen als künstlich erzeugte IDs. Und es da schon wirklich echter Argumente bedarf, um stattdessen einen substitute key einzuführen.

Lustig...ich bin zu 100 % gegensätzlicher Meinung...Aber diese Diskussion wird ja seit Erfindung des relationalen Modells geführt . Was wären den deine Gründe für "fachliche" PK's ?


Gruss

 

[Biber2]

Moin dbwizard,

ich weiss, dass das auch eine der ewigen Glaubenkrieg-Fragen der IT ist.
Will da auch lieber nicht einen Absolutheitsanspruch erheben. ;-)

Aber zwei Argumente habe ich schon.

1) Bei den "simplen" Entities wie Kunden- oder Artikel-Tabelle ist ein "künstlicher Schlüssel", egal ob Integer, AutoIncrement oder GIUD immer auch ein redundanter "alternate key" zur ohnehin enthaltenen Kundennummer oder Artikelnummer.
Extrem bei Dimensionstabellen/Kennzeichen-Tabellen.


Und Redundanz ist sind immer ein zusätzliches Risiko in DB-Modellen - ausserdem stehst du spätestens bei telefonischen Supportanfragen dumm da, wenn der Kunde dir erzählst, das Artikelnummer "4711" oder "0815" eine falsche Bezeichnung hat und du diesen (performanten) PK-Index auf einem Kunst-Integerkey wie 187263541 liegen hast (den du aber nicht immer im Kopf hast)

2) ich arbeite hauptsächlich in Datawarehouse-Projekten. Da werden ohnehin oft auf Gründen der Historierung "neue" künstliche Schlüssel vergeben/generiert.

Wenn nun aber aus einer Quell-Tabelle schon ein Kunst-Key geliefert wird, der auf dem Weg ins Datawarehouse einen neuen Kunstkey bekommen muss (das ist noch stressarm), aber dann wie üblich mal 34 der 3 Mio Datensätze NICHT richtig (wie designed) den Weg finden von der Datenquelle bis in der Presentationlayer des DWH.... dann viel Glück bei der Rekonstruktion des kleinen Fehlers, wenn du nur lustige Querys mit 12stelligen Integers machen kannst. Da wirst du weich in der Brezel.

@Eroli
Hmmm... wieso sollte ich, wenn VARBINARY(16) gemeint hätte, wohl BINARY(16) geschrieben haben?
Da is' nix VAR dran... und das ist die VARheit...*gg

Grüße
Biber

 

[Eroli]

@Eroli
Hmmm... wieso sollte ich, wenn VARBINARY(16) gemeint hätte, wohl BINARY(16) geschrieben haben?
Da is' nix VAR dran... und das ist die VARheit...*gg

Weil mein MySQL Workbench Tool BINARY(X) nicht kennt, sondern nur VARBINARY(X) oder BINARY. Das hat mich verwirrt. Was denn nun?

 

[Biber2]

Moin Eroli,

okay, jetzt versteh ich die Frage, sorry.
Logisch -wenn du "Binary(16)" nicht syntaktisch durch deinen Parser bekommst->klar, dann VARBinary(16) -oder- eben "nur" BINARY" (ohne Klammerauf-16-Klammerzu).
Soooo wichtig ist es ja nicht.
A propos wichtig ... demnach klebst du doch irgendwie an diesen GUIDs/UUids? *gg

Grüße
Biber