Hallo,
ist es angedacht, uuids als Primärschlüssel zu benutzen?
hi,
bisher nicht. Siehst Du da vielleicht Vorteile für metasfresh?
Viele Grüße
Norbert
Hallo,
ich sehe grosse Vorteile in der Benutzung von UUIDs als Primärschlüssel, nicht nur für metasfresh…Wenn UUIDs ausgewürfelt werden, kann man z.B. riesige Datenbestände, die erst mal nichts miteinander zu tun haben, einfacher miteinander verbinden, ohne das lästige Gefummel mit Namensräumen (z.B. zwei Datenbestände in einen zusammenführen).
Mit UUIds als PK ist es auch einfacher, für (wirklich) grosse Datenbestände eine Historie zu haben; es wird auch nach vielen Jahren eher nicht vorkommen, dass ein PK, der in der Vergangenheit benutzt wurde und nun in einer History lagert, nochmal vergeben wird. Bei 10^10 möglichen PKs ist das (natürlich nur in einem wirklich grossen Bestand) schon mal möglich.
Dadurch, dass UUIDs auch mit einem kryptographisch sicherem Zufall erzeugt werden können, sind sie nicht vorhersagbar (so sollte es zumindest sein, wenn der Zufall nicht kaputt ist). Es gibt Umgebungen, in denen sowas gefordert ist.
Edit: man kann damit auch einen Prima-Cache bauen, der Unabhängig von irgendwelchen Datentypen ist.
vG
Hallo @metaeval,
wir haben UUIDs als PKs in der Vergangenheit immer mal wieder diskutiert und auch hier und da schon mal eingesetzt. Mir fällt hierzu unsere Vaadin-Anwendung ein, mit der Landwirte auf dem Feld per Handy erfassen, wie viel sie vorraussichtlich werden liefern Können. Diese Meldungen laufen in die metasfresh-Beschaffungsplanung ein und werden mit UUIDs eindeutig identifiziert.
Wir sehen auch die allgemeinen Vorteile, die zu nennst, aber wir sehen im Moment keinen konkreten Nutzen darin, auf breiter Front umzustellen.
UUIDs sind nämlich dadurch dass sie länger sind auch schwerer zu handhaben…z.B. kann ich mit eine Integer-ID im Zweifel kurz merken und aus dem Gedächtnis z.B. bei pgAdmin eintippen.
Außerdem müssten wir erstmal schauen, wie es mit der Performance und Indizierbarkeit bei Postgres aussieht.
Und allgemein finde ich auch “If it’s not broken, don’t fix it” 
Aber in Einzelfällen sehe ich es wie Du, UUIDs können viele Vorteile gegenüber Integer-Keys haben.
VG Tobias
Das mit dem Gedächtnis ist ein Argument…
Zu Postgres kann ich dir sagen: es funktioniert richtig gut, auch mit JPA dazwischen. iirc legt Postgres eine UUID intern als 128 bittigen Integer an (andere Datenbanksysteme handhaben eine UUID als String, Sqlite, glaube ich, und auch MSQL, wenn mich die Erinnerung nicht trübt).
Bei einem früheren Arbeitgeber, wo es richtig dicke Datenbestände gab (mehrere Mio Sätze/Tabelle), hat die Umstellung auf UUIDs einen deutlichen Performanceschub gebracht, auch bei partitionierten Tabellen. Dort gab es für die Kunden die Auswahl zwischen Postgres und MSQL, postgres hat da nach der Umstellung auf UUIDs ein deutlich besseres Bild abgegeben, zumindest bei den richtig grossen Beständen (soll jetzt kein MS-Bashing sein).
Aber mit den Details bin ich nicht so berufen; da gab es jemanden, der sich damit besser auskannte. Für mich war beim DAO Schluss.
vG
metaeval
1 Like