Hallo Holger,
wenn ich dich richtig verstanden habe, verwendest du ein BigInt als PK und reservierst ein gewissen Range für jede NL.
Dabei sind deine NL-IDs wahrscheinlich fix und werden sich nicht ändern. In meinem Fall darf ich nicht davon ausgehen.
Mein Client läuft komplett ohne Installation einfach alles auf ein Stick kopieren und direkt vom Stick laufen lassen.
Diese Freiheit hat zur Folge, das Anwender den Stick einfach kopieren und laufen lassen. Somit habe ich die gleiche
NL-ID ein zweites mal.
Es ist so, wenn das Projekt abgeschlossen ist, stört mich die fehlende Lesbarkeit der UUIDs eher weniger. Während der
Entwicklungsphase ist es halt sehr störend.
Der Hinweis von SX2008 ist hier sehr wichtig. Das würde bedeuten dass die Anwendung insgesamt träger sein wird bei normalen
Operationen wie Select, Update und Delete. Das ist natürlich sehr sehr schlecht und spricht doch sehr gegen UUIDs.
Wenn sequentielle UUIDs genau so eindeutig sind wie die aktuelle Version der UUIDs stellt sich die Frage warum gibt es
die Funktion in Firebird nicht? Sicherlich könnte man dafür eine UDF schreiben aber die wird deutlich langsamer sein als
eine interne Funktion.
Um nicht gleich die Flinke ins Korn zu werfen, müsste man in Sache Performance mit den derzeitigen UUIDs mehr Erfahrungsberichte haben.
Auf die Gefahr hin das ich jetzt gesteinigt werde
bringe ich einen weitere Vorschlag der zwar zu meinen Konzept nicht passt aber
bezüglich Filialenfähigkeit:
-Wenn die Filialen(FL) eindeutig sind und man sicherstellen kann dass sie nicht "kopiert" werden wie bei mir, könnte man
den PK auch als Double anlegen. die Nachkommstelle ist die FL-ID darüber habe ich schon lange nachgedacht aber mich nie getraut
das mal auszuprobieren.
Für meinen Fall habe ich gerade eine Blitz-Idee.
-Ich designe alle PKs als normale integer.
-Die Filialen(FL) werden nicht unterschieden!
-Weiterhin kann eine Installation kopiert werden.
-Die Datenbankstruktur unterscheidet sich zwischen FL und der zentralen Datenbank.
Dabei haben ich ja das Problem dass beim Abgleich die IDs gleich sein können.
So jetzt zur Lösung:
-Wenn eine Filiale einen neuen Datensatz anleget, wird die ID ins minus angelegt.
-Die zentrale Datenbank macht das nicht. Sie macht positive IDs.
-Wenn der Client die Daten an den Server sende will, muss er zwangsläufig sich mit meinem Kommunikationsserver verbinden
der für den Datenabgleich zuständig ist. Der Client geht alle Tabellen in der RICHTIGEN Reihenfolge durch und fordert
für jeden neuen Datensatz innerhalb dieser Tabelle eine neue ID von der zentralen
DB an. Der Client überschreibt seine negative ID durch die positive ID
von der zentralen
DB. Das Update Cascade in der ClientDB führ dazu dass alle FKs aktualisiert werden.
-Jetzt können die Daten im zweiten Stepp problemlos übertragen werden denn sie haben eindeutige IDs von der zentralen
DB.
-Somit ist es egal wie viele FLs existieren und sogar egal auch wenn die
DB kopiert wird.
-maximale Performance wegen integer oder bigint.
[Edit]
-Keine UUID oder
GUID notwendig (sind langsam da sie nicht sequenziell angelegt werden innerhalb einer Instanz)
-Kein Konflikt mehr bei den PKs
-Ich weiß ob der Client neue Daten zum Senden hat, eben wenn in irgend einer Tabelle ein negativer Wert als PK
steht.
Was noch offen bleibt ist, wie Änderungen von vorhandenen Datensätzen abgleichen.
Ein Update-Konflikt-Management bleibt nicht aus. Dafür werden Regeln gebildet die
bei Konflikt vorschreiben was zu tun ist.
Um das zu vereinfachen:
-Tabellen werden normalisiert und dabei auf die Regeln geachtet.
-Wenn ein Feld vom Client und vom Server geändert wurde, muss die Regel sagen wer Recht hat.
-Dafür muss eine Tabelle unter Umständen in so vielen einzelnen Tabellen zerlegt werden mit Referenz 1:1
so das die Regel für alle Felder gilt. D.h. z.B.: die Tabelle Adress wird zerlegt in Tabelle AdressC
und AdressS.
-Wenn irgend ein Feld aus AdressC von Client und Server geändert wird, hat der Client Recht.
-Wenn irgend ein Feld aus AdressS von Client und Server geändert wird, hat der Server Recht.
-Theoretisch könnte es eine AdressU geben bei einem Konflikt User fragen.
Somit ist auch das Update sehr leicht nachvollziehbar.
[/Edit]
Das hört sich doch ziemlich gut an und ist sehr leicht umsetzbar.
Gruß Kostas