"Synchronisations-Theorie"

[Philipp Hasenfratz]

Halihallo Klaus

Auweia, da muß ich mir doch glatt was neues überlegen. Da kommt aber wieder eine andere Variante ins Spiel, die ich von Philipp Hasenfratz habe und von der mich Sven Rautenberg nur mit Mühe abbringen konnte:
Ich teile den "ID-Raum" untern den Systemen auf, z.B. System 1 hat IDs von 1.000.000.000 bis 1.999.999.999 usw.

Da hatte er sicher Recht, wobei zu bedenken ist, daß zwei Felder mit 32 Bit praktisch einem berechneten Feld mit 64 Bit ist. Allerdings muß man so viel beachten, vro allem die Möglichkeiten der Datenbank, daß auch ich glaube, daß es besser ist, mit zwei Feldern zu arbeiten.

Warum zwei 32Bit? - Andreas hat keine 2^32 Datenbanken, glaub ich zumindest ;-)
Du brauchst ja nur ca. 8bit für die DatenbankID und den Rest für die ID der Records. Ja, mit zwei Feldern zu arbeiten wäre in der Tat viel besser, aber: dann hast du ein Feld DatenbankID und eine ID mit autoinc. Jeder Datensatz ist bezogen auf das System unique, aber dann müsste Andreas die DatenbankID immer noch in die SQL Abfragen einfügen => ARBEIT...

Und autoincrement kannst Du afaik auch gleich vergessen. Das ist zu unflexibel für diese Art von Anwendungen.

Ja, den müsste man selber implementieren. Klar, wenn man den ID Raum aufteilt, kommt man nicht darum herum; es sei denn man könnte den startindex im Tableheader festlegen.

Kann man das vielleicht mit Foreign Keys lösen? Ich hatte eh vor erst alle Datensätze zu löschen und zu überschreiben!

Foreign-Keys haben mit den konsistenten Beziehungen der Daten in verschiedenen Tabellen zu tun, niicht mit der ID-Generierung. Die ID's müssen schon vorher festgelegt sein.
Und Löschen und Neuschreiben finde ich für wirklich gefährlich. Was, wenn aus irgendeinem Grunde das Insert nicht mehr funktioniert? Woher sollen dann die Daten rekonstruiert werden. Denke auch an unvorhergesehenes wie Stromausfälle und so weiter. Konsistenz ist für solche Sachen oberstes Gebot.

Nun, bei der Synchronisation treten ja leider noch mehr Probleme auf: Was, wenn der Datenbestand auf einer DB ändert, noch während der Synchronisation? - In den meisten Fällen kann man das mit den Flags und Timestamps ja "unterbinden", aber 100% ist die Lösung auch nicht. Man müsste theoretisch während der Synchronisation die Table locken, bzw. wirklich jeden Datensatz hin und her schaufeln und alles "asynchron" (also immer senden/empfangen von einem Datensatz, nicht synchron: das ganze Packet hin und zurück) abarbeiten.

Viele Grüsse

Philipp