Synchronisation zwischen Datenbanken - Ideen?

[gmc616]

Hmm ... das "Update-Liste pro Client"-Konzept ist auch eine Lösung.
Allerdings muß hier geklärt sein, welche DB die Master-DB stellt.

Wenn ich den TO richtig verstanden habe, wird auf beiden DBs aktiv gearbeitet.
Die Synchronisation muß also in beiden Richtungen stattfinden. Und da kommt man an einem Zeitstempel nicht vorbei. Allzumal die Synchronisation nicht zeitgleich passiert sondern mit Sicherheit in bestimmten zeitlichen Intervallen.

Wie soll man verhindern, das z.B. Online ein Termin gelöscht und gleichzeitig (im gleichen Zeitintervall) der selbe Termin lokal nur verschoben wird. Oder auch umgekert. Das sind zwei unterschiedliche Vorgänge auf ein und die selbe Information (sprich Datensatz)!

Selbst ein Mischen und Sortieren der Updatelisten beider DBs kann zu Datenverlust führen.

Löschen von Datensätzen, die mit anderen DB's Synchronisiert werden sollen, halte ich daher immer für einen schlechte Idee. Eine Löschmarkierung ist hier der bessere Weg.

Ich glaube grundsätzlich kann man sagen, dass das Synchronisieren von zwei (oder mehreren) DBs immer ein Problem darstellt und sollte immer von Anwendungsfall zu Anwendungsfall neu überdacht werden.

Meines Erachtens ist es das wichtigste, das Termine (Datensätze) auf allen DBs einen eindeutigen ID besitzen, damit man sie jederzeit identifizieren kann.

Zitat von BUG:

Nett wäre hier, wenn nicht ein anderer Client gleichzeitig auch versucht zu synchronisieren.

Das definitiv.

[Sir Rufo]

Die Update-Liste braucht man eigentlich nur auf dem Server, da dort die ausstehenden Änderungen pro Client gespeichert sind.
Gut so eine Tabelle kann der Client auch führen, dann ist das Handling der gelöschten Sätze einfacher.

Einen Timestamp sollte man bei der Haupttabelle haben.

Ein Löschen kann generell nicht verhindert werden, wenn das Löschen möglich sein muss.
Wie wäre denn der Fall, wenn alle an einem Server arbeiten?
Der Datensatz ist weg.

Selbiges gilt für das Ändern von Datensätzen, da gewinnt die letzte Änderung.
Um die herauszufinden benötigt man den Timestamp vom Client.

Und da wartet schon die nächste Hürde:
Am Client wird die Uhrzeit 3h vor gestellt und schon würden alle jetzt gemachten Änderungen gewinnen.

Das ist aber auch schon fast ein anderes Thema.
Hier ging es ja zunächst um die Sicherstellung, dass alle Objekt repliziert werden

[FredlFesl]

Für eindeutige IDs würde ich eine GUID nehmen. Ohne die geht es nicht.

Die Tabelle der durchgeführten Änderungen (eingefügt, gelöscht, verändert) als Basis für den Synchronisationsprozess ist schon richtig.
Wenn Du dann noch Konflikte behandelst (Änderungen widersprechen sich), bist Du fertig.
Ein Konflikt tritt z.B. dann auf, wenn der eine einen Datensatz löscht, ein Anderer den gleichen DS zwischenzeitlich jedoch verändert hat.
Oder beide verändern ein und das selbe Feld eines DS.

Du kannst hier entweder nach dem Prinzip "Last one wins" vorgehen, oder Du implementierst eine Konfliktbehandlung ("DS xy wurde von Schulze am BLABLA verändert, aber von Ihnen am BLABLUB gelöscht"). Da beim ersten Fall Datenänderungen unbemerkt verschwinden können, würde ich eine Konfliktbehandlung ("reconcile") implementieren. Das ist übrigens das sog. "briefcase model".

Um solche Konflikte sicher erkennen zu können, könntest Du dir merken, "wann" (und vom wem) ein Feld zum letzten Mal geändert wurde. Liegt dieser Zeitpunkt NACH deinem letzten Abgleich (und du hast diesen DS/Feld) verändert, liegt ein Konflikt vor.

Konfliktbehandlungen bekommst Du auch in den Griff, wenn Du dir eine Kopie der DB ("Original") nach erfolgter Synchronisation erstellst und vor der nächsten Synchronisation die Daten mit dieser DB-Version vergleichst: Hat sich ein zu ändernder Datensatz (Von 'A' nach 'B') zwischenzeitlich verändert, war die Änderung nicht exklusiv, es liegt dann also ein Konflikt vor. Du vergleichst also jeden DS VOR dem Abgleich mit dem Original. Damit erkennst Du zwar Konflikte, nicht jedoch, WER der Konfliktpartner ist.

Ich würde den ersten Weg wählen: Man hat auch eine sehr mächtige Änderungshistorie, was bei Geschäftsdaten nicht unerheblich ist. Du kannst dann auch Fragen beantworten, wie: "Wer hat denn damals den Ansprechpartner von Fa. Halmackenreuther geändert".