Hallo Manfred,
ich kenne die FibPlus-Komponenten nur vom Hören-Sagen. Dein
DB-Schema mit ID CHAR(38) deutet daraufhin, dass diese Komponenten einen
GUID genauso gut oder schlecht verarbeiten, wie andere auch. Grundsätzlich ist es richtig, dass
GUID-Felder das Arbeiten mit global verteilten Datenbanken unterstützen. Der von dir erwähnte Abgleich der Daten über das Internet mag als Offline-Betrieb einer horizontal verteilten Datenbank gelten. Ein
GUID-Feld ist dafür allerdings nicht zwingend erforderlich, du brauchst ja keine weltweit eindeutigen Schlüssel - anwendungsweit würde ja schon genügen. Ich würde eher mit einer Identität aus der problem domain arbeiten (Versicherungsnummer, Personalnummer, etc.). Immerhin muss ja beim Abgleich der Mensch identifiziert werden und nicht der Datensatz.
Aber da hängt vieles von Feinheiten ab. Eine zentral gepflegte Datenbank, deren Tupel regional verteilt werden, lokal aber nur gelesen werden, braucht zum Beispiel keinen
GUID als Schlüssel. Und bei kleinen Datenmengen würde man auch keinen Abgleich fahren, sondern die lokalen Daten komplett ersetzen. Wenn du also abgleichen willst, dann scheinen die Daten lokal auch gepflegt zu werden. Dabei kommt es wieder darauf an, ob nur UPDATE zulässig ist oder auch INSERT und DELETE. Das Thema ist extrem komplex. Ich fürchte wir werden es hier nicht erschöpfend behandeln können.
Lass dich von mir nicht irritieren. Ob
GUID oder GEN_ID - mit einem primary key machst du schonmal nichts falsch. Die Tupelzahlen dürften bei dir klein bleiben, so dass der space-time overhead durch einen PK mit CHAR(38) nie ins Gewicht fällt.
Viel Erfolg mit deinem Projekt.
marabu
PS: Vergesse den Datenschutz bei personenbezogenen Daten nicht.
Zitat
Baum-Darstellung
