Umsetzung einer Datensynchronisierung zwischen zwei Datenbanken

[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.

[BUG]

Zitat von jobo:

ich würde aber "ausschließlich technisch" sagen.

Stimmt schon natürlich

Zitat von Sir Rufo:

Statt eines Zeitstempels nimmt man eine RowVersion und inkrementiert diese bei jeder Änderung des Datensatzes.

Damit lässt sich schon etwas anfangen. Aber dafür müssen die Daten halt passend strukturiert sein und man muss sich vorher Gedanken gemacht haben, was passieren kann.

Namen wir an, wir haben eine Datenbank und jeder Nutzer hat ein Punktekonto (id, punkte). Während der Client getrennt ist, überweist dieser 5 Punkte von Alice an Bob. Auf dem Onlineserver bekommt Bob 10 Punkte für gutes Benehmen gutgeschrieben.
Wenn ich dann nicht auch die Transaktionen als neue Spalte gespeichert haben, dann kann ich Fehler zwar erkennen, für die Fehlerbehebung (selbst manuelle) sieht es düster aus.

[madas]

Zitat von BUG:

Namen wir an, wir haben eine Datenbank und jeder Nutzer hat ein Punktekonto (id, punkte). Während der Client getrennt ist, überweist dieser 5 Punkte von Alice an Bob. Auf dem Onlineserver bekommt Bob 10 Punkte für gutes Benehmen gutgeschrieben.
Wenn ich dann nicht auch die Transaktionen als neue Spalte gespeichert haben, dann kann ich Fehler zwar erkennen, für die Fehlerbehebung (selbst manuelle) sieht es düster aus.

Für diesen Fall kann man ja History-Tabelle mitführen.

Sprich wenn (Client.RowVersion > Client.RemoteRowVersion) && (Server.RowVersion > Client.RemoteRowVersion) dann müsste man mit den History-Tabellen arbeiten bzw. diese beim Abgleich mit einbeziehen.

[RWarnecke]

Hallo zusammen,

danke für die vielen Antworten. Ich glaube, dass ich für mein Vorhaben das nochmal überdenken muss, ob ich wirklich eine Synchronisierung in zwei Richtungen realisiere. Nach den ganzen Posts, tendiere ich immer mehr zu einem Live System, wo das mobile Gerät direkt über einen Dienst auf die Datenbank zugreift.

Aber ich bin immer noch für weitere Vorschläge offen, da es ja bis jetzt immer noch irgendwo einen Haken gibt. Wobei ich sagen muss, je länger ich darüber nachdenke, es aus meiner Sicht keine hundertprozentige Lösung für die Konstellation SQLite <--> FirebirdSQL und SQLite <--> MSSQL gibt. Da die Software, die auf dem Desktop genutzt wird beiden Datenbanken unterstützt (MSSQL und FirebirdSQL).

[Sir Rufo]

@BUG

Es gibt Stammdaten (Alice, Bob), Bewegungsdaten (5 Punkte von Alice nach Bob, 20 Punkte an Bob) und dann die kumulierten Daten (Saldo für Alice, Bob).

Die Stammdaten und Bewegungsdaten werden zwischen den Systemen ausgetauscht. Die kumulierten Werte bildet jedes System selber.

Nur so zum Verständnis, ein Update sieht dann z.B. so aus

Delphi-Quellcode:

Query.SQL.Text := 'UPDATE person SET version = version+1, deleted = :deleted, name = :name WHERE id=:id AND version = :version';
Query.ParamByName('id').Value := aPerson.Id;
Query.ParamByName('version').Value := aPerson.Version;
Query.ParamByName('deleted').Value := aPerson.Deleted;
Query.ParamByName('name').Value := aPerson.Name;

Query.ExecSQL;

if Query.RowsAffected = 0 then
  raise EConcurrencyException.Create('Datensatz wurde schon vorher geändert');

[jobo]

Zitat von BUG:

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.