Umsetzung einer Datensynchronisierung zwischen zwei Datenbanken

[RWarnecke]

Hallo zusammen,

ich habe die Aufgabe eine Synchronisierung zwischen einer SQLite Datenbank und den zwei Datenbanken FirebirdSQL oder MS-SQL zu realisieren. Die SQLite-Datenbank ist auf einem mobilen Gerät, welches im ersten Schritt über WLAN mit den entsprechenden Servern (FirebirdSQL oder MSSQL) die Daten synchronisieren soll. Dabei sollen lediglich nur die entsprechenden Daten synchronisiert werden, so dass es die Möglichkeit gibt die Daten auch Offline zu nutzen. Die Synchronisierung soll in beide Richtungen erfolgen.

Meine Frage, wie kann man jetzt am besten so eine Synchronisierung realisieren ? Dabei geht es nicht um Quelltext sondern um den Aufbau und den Ablauf.

[Bambini]

Zitat:

Zitat von RWarnecke (Beitrag 1336789)

Dabei geht es nicht um Quelltext sondern um den Aufbau und den Ablauf.

Wenn auf beiden Datenbanken gearbeitet wird, kommt man an einem Transaktionslog nicht vorbei.
Jede Datenbank protokolliert welcher Datensatz in welcher Tabelle ukModify, ukInsert oder ukDelete wurde, mit Datum und Uhrzeit.
Dieses Log wird dann beim Sync auf der anderen DB nachgeführt. Spannend wird es wenn es Kollisionen geben kann, d.h. auf beiden Seiten wurde am gleichen Datensatz geändert oder gar gelöscht. Um dies zu erkennen, muss beim Sync beide Transaktionslogs gelesen, verglichen und dann erst abgeglichen werden.

Auch unklar: Was passiert bei abhängigen Daten. Eine Eintrag in der Tabelle 1 hat 1:n Einträge in Tabelle 2. Jetzt löscht einer einen Eintrag in Tabelle 1, vermutlich werden die lösch-Statements für Tabelle 2 auch im Log stehen, aber wenn die andere Seite Einträge in Tabelle 2 hinzugefügt hat??

[hstreicher]

Also ich kenne da 2 Möglichkeiten

1) in die Records ein Flag einbauen "Muss syncronisiert werden" geht aber nur für 1:1 Also 1 Mobilgeräte auf eine Grosse DB

2) Trigger die Geänderte Daten (oder Referenzen darauf) in eine "ToDo" Tabelle schreiben , hier wären bei mehreren Syncronisationspartnern dann eben ein Eintrag pro Ziel notwendig

mfg Hannes

[Bambini]

Zitat:

Zitat von hstreicher (Beitrag 1336797)

1) in die Records ein Flag einbauen "Muss syncronisiert werden" geht aber nur für 1:1 Also 1 Mobilgeräte auf eine Grosse DB

Wie klappt das bei ukDelete?

[hstreicher]

wie bei DBase und Co ein Deleted Flag und erst nach der Sync löschen

aber die 2 Lösung ist eh besser

[Rollo62]

Käme das Briefcase Modell in Frage ?
http://docwiki.embarcadero.com/InterBase/XE7/en/Using_the_Briefcase_Model

http://www.drbob42.com/examine/examin64.htm
https://en.wikipedia.org/wiki/Briefc...oft_Windows%29

Rollo

[mm1256]

Hallo Rolf,

ClientDataset ist schon mal ein guter Gedanke. Die Tücke steckt aber im Detail, wenn die Synchronisierung in beide Richtungen erfolgen soll. Doch das ist dir ja wohl selber bewusst, sonst würdest du nicht fragen. Also, ich hatte so eine Synchronisierung jahrelang (2003 bis ca. 2010) im Einsatz. Zwar nur mit Notebooks (wo ich wenigstens die selbe Datenbank aufsetzen konnte) aber die Probleme sind die gleichen. Mit einem einzelnen Flag pro Datensatz (ich hatte hierzu ein Feld Timestamp der letzten Änderung im Einsatz) kommt man nicht weit. Das ist bestenfalls für die Performance-Optimierung beim Abgleich zu gebrauchen. Es muss jede Änderung pro Datensatz und Datenfeld protokolliert werden. Idealerweise in einer DB die dann beim Synchronisieren abgearbeitet wird. Und selbst dann kann es noch Ärger geben, wenn z.B. beim gleichen Datensatz das selbe Feld von unterschiedlichen Usern verändert wurde.

Wer gewinnt? Den User fragen wäre eine mögliche Variante, doch selbst das müsste man dann wieder protokollieren, denn sonst zieht deine Hotline die A-Karte und Ärger ist irgendwann vorprogrammiert. So viel ist nach meiner Erfahrung sicher.

Abhilfe: Datentransfer nur in einer Richtung. Wenn jemand unbedingt beide Richtungen haben will, dann soll er besser Geld in eine Online-Lösung (Teamviewer, Remote-Desktop...) investieren, als in eine Datenbank (Sonder-)Programmierung die sowieso langfristig gesehen mehr kostet.

Darum ein gut gemeinter Rat: die Finger von der Umsetzung "in dieser Art und Weise" lassen. Es gibt genügend fertige Alternativen.

[BUG]

Meiner Meinung nach ist es oft ein Fehler, solche Sachen von der technischen Seite anzugehen (und nachträglich irgendwo reinzufummeln).

Was sind das für Daten (semantisch)? Welche davon können geändert werden? Welche Teile der Daten sollen nur atomar/zusammen geändert werden? Was ist der konsistente Zustand / ein Konflikt. Wie gehe ich mit einem Konflikt um? Wer kann Konflikte beheben (betrifft ja auch Rechteverwaltung)? Gibt es Rollen oder Operationen, die Vorrang gegenüber anderen haben?

Danach kann man überlegen: Welche zusätzlichen Daten brauche ich, um Konflikte zu erkennen und zu evtl. beheben. Dabei sollte man auch daran denken, das z.B. Zeitstempel in verteilten Systemen selten eine gute Lösung sind.

[Sir Rufo]

Statt eines Zeitstempels nimmt man eine RowVersion und inkrementiert diese bei jeder Änderung des Datensatzes. (MSSQL hat den Datentyp schon integriert und inkrementiert auch automatisch)

Server

• ID int
• Version RowVersion
• Deleted bool

Client

• ID GUID
• Version RowVersion
• Deleted bool
• RemoteId int (Server ID)
• RemoteVersion RowVersion (Server Version)

Mit den Informationen lassen sich neue, gelöschte und geänderte Datensätze finden sowie Änderungskollisionen feststellen.

[jobo]

Zitat:

Zitat von BUG (Beitrag 1336857)

Meiner Meinung nach ist es oft ein Fehler, solche Sachen von der technischen Seite anzugehen

Sehr gut, ich würde aber "ausschließlich technisch" sagen.
"Was brauche ich eigentlich?", diese Frage dürfte am Anfang stehen.

- gelöschte Datensätze
Sollte kaum der Fall sein. Sobald es um geschäftliche Dinge geht, ist man schnell verpflichtet, aufzubewahren. Notfalls tut es ein Löschflag.
- konkurierende Änderung, auch eher selten, Klassiker wäre die Außendienst-Verkaufssoftware. Hier gibt es meist aus unterschiedlichsten Gründen Vertriebsregionen und genau festgelegte Kundenkreise, da konkurriert nichts. Eine Grundsätzliche Ausnahme wäre der Verkauf von physikalisch beschränkt vorhandenen Dingen. (Elektroautoprämie) Dafür wäre ein Offlinesystem aber wirklich nicht geeignet.

Damit wären die "schlimmsten" Fälle beispielsweise wegdefiniert. Eine Implementierung muss also nicht so umfangreich ausfallen.

Und ja, dafür gibt es auch fertige Bibliotheken. Ich hab mir mal sowas angeschaut. Eines hat mir sehr gut gefallen. Der Kunde wollte dafür aber nichts zahlen (Lizensierungskosten, laufende Kosten), es war kommerziell kostenpflichtig. Das System (generisch) hat zur Abbildung der Funktionalität ca 40 eigene Tabellen verwendet, wenn ich mich richtig erinnere. Soviel zum Thema 1 Flag - Lösung.