Konzeptionelle Frage - Datenabgleich

[himitsu]

So mancher nimmt hier als ID einen TIMESTAMP (mit Millisekunden) oder sowas wie eine GUID
und geht erstmal davon aus, dass es womöglich fast nie vorkommt, dass auf beiden Seiten genau zur selben Zeit ein Datensatz hinzukommt. (was natürlich aber dennoch einmal passieren könnte)



Da es aber dennoch ab und an mal vorgekommen ist, habe ich bei uns einige der Synchronisationen umgestellt.
Also intern wird mit einer Integer-ID gearbeitet, welche aber nur innerhalb einer DB genutzt wird, aber bei der Synchronisierung werden eine/mehrere andere eindeutige Spalten genutzt
und diese ID wird bei der Datenübertragung ignoriert.

Eventuell wird auch diese ID noch "umgerechnet", falls weitere Tabellen ebenfalls synchronisiert werden und sich über diese ID referenzieren.
Also in allen Tabellen/Daten diese ID von lokaler DB durch ID der anderen DB ersetzt, bei der Datenübertragung (referenziert über die Synchronisationsfelder).

[Neumann]

Mache folgendes:

Alle Tabellen, die gesendet oder empfangen werden, bekommen 3 zusätzliche Felder:
Lastchange Timstamp wird per Trigger gesetzt
Lastupdate Timestamp wird gesetzt wenn Datensatz exportiert wird, dann NOW + ein paar Sekunden
AGUID wird erzeugt wenn Datensatz erstmalig gesendet wird.

Der Empfänger prüft dann ob AGUID schon existiert, wenn ja dann Update sonst Insert.
Natürlich muss man noch auf Nummernkreise und ev. AutoInc-Felder achten.
Löschbefehle komme in Del-Tabellen, die auch automatisch angelegt werden.

Kommunikation geht entweder über eine einfache Soap-Schnittstelle oder über Dateien, die z.B. in einer Dropbox o. ä. geschrieben werden.
Bei Dateien liest der Empfänger die Daten ein und löscht sie dann.

Die Daten sind im JSON-Format.

Ich benutze eine sehr nützliche Funktion aus dem Delphi-MVC Framework, die sehr einfach den Export und Import von JSON-Arrays in Datasets ermöglicht.

Gibt natürlich noch einige Details, aber kann das jetzt nicht alles beschreiben

[himitsu]

Zitat von Neumann:

Lastchange Timstamp wird per Trigger gesetzt
Lastupdate Timestamp wird gesetzt wenn Datensatz exportiert wird, dann NOW + ein paar Sekunden

Hier kann man sich nun auch noch streiten.
Wir haben sowieso an fast allen Tabellen ein paar automatisch angelegte Felder für InsertTime, UpdateTime und wer das war.

Aber zusätzlich gibt es an synchronisierten Tabellen auch noch dieses "Modified"-Feld für die Synchro, wobei dieses Feld nicht nur angibt wer neuer ist, sondern auch für den Vergleich benutzt wird.
> Tja, nutzt man dieses Datumsfeld nun für einen billigen "hat sich was geändert"-Vergleich, oder vergleicht man da wirklich alle Spalteninhalte? (ausgenommen denen, welche von der Synchro ausgeschlossen sind)

[Hobbycoder]

In einer kleineren Testumgebung habe ich das vor relativ langer Zeit mal so gelöst:

Keine Replication auf DB-Ebene. Je eine DB an jedem Standort, und diese einmal vollständig übertragen.
Jede Tabelle hat ein Lock-Feld.

Wird nun ein Datensatz an Standort A zum Bearbeiten geöffnet, so wird sowohl der Datensatz sowohl in DB A als auch in DB B mittels dem Lock-Feld gesperrt. Heißt er kann nur noch zum Lesen geöffnet werden. Wird er nun in DB A gespeichert, dann wird dort das Lock direkt aufgehoben. Anschließen wird er dann in DB B gespeichert und erst danach das Lock auch dort aufgehoben.
Das ganze muss natürlich im Client passieren, oder man muss den DB-Zugriff über eine Server-Application regeln, die dann das Sperren und Entsperren passig übernimmt.
In die andere Richtung würde das genauso funktionieren. Und auch mit mehr als 2 Standorten.

Hat, wenn ich mich recht erinnere damals ohne Probleme funktioniert. War aber nur ein Test. Wir haben damals zwar einige an Traffic simuliert, aber ob es einem Echt-Betrieb standgehalten hätte kann ich nicht mit Sicherheit sagen. Sollte aber.

Das natürlich 2 User auf beiden Seiten zeitgleich den gleichen Kunden anlegen kann dieses Verfahren natürlich nicht verhindern. Und das Handling ist natürlich auch von der zur Verfügung stehenden Bandbreite abhängig.

Ob sich sowas auch auf DB-Ebene realisieren ließe, kann ich nicht sagen. Dazu fehlt mir das Wissen.