Synchronisierung von Daten zwischen Systemen

Es sollen einige Daten zwischen 2 System synchronisiert werden, aktuell fließen die Daten nur in eine Richtung.

Die Architektur sieht wie folgt aus.

DB-1 <--> Ex/Import-Tool/Dienst <--> WebAPI <--> DB-2

Es soll es die Möglichkeit geben das einige Daten z.B. Mitarbeiterstammdaten (E-Mail, Telefonnummer, ...) auf beiden Seiten geändert werden können und somit synchronisiert werden müssen.

Wie geht man da am besten bei der Implementierung vor?

Meine Idee ist bisher für jedes Feld einen Zeitstempel aufzunehmen, um zuerkennen wann wurde was zuletzt geändert.

Hast Du denn allgemein schon mal nach best practises zu dem Thema gesucht?
Es gibt hunderte Möglichkeiten, sowas umzusetzen...

Ich würde sowas ehrlich gesagt nicht (mehr) selbst umsetzen, sondern mit ein entsprechendes Framework suchen, das zu Deinen Anforderungen passt.

Danke für die schnelle Antwort.

Ja gesucht und mit Kollegen diskutiert. Ich bin auch nicht gerade scharf drauf es selbst zu umzusetzen.

Aber neben der Synchronisierung der Daten kommt noch eine Führung eines Bediener/Änderungslogbuch hinzu. Und ich denke spätestens dieses muss ich selbst implementieren. Denn die Struktur ist nicht einfach eine Textdatei, sondern recht umfangreich und detailliert auswertbar (Was, Wann, Wo, Wer, ...).

Aber neben der Synchronisierung der Daten kommt noch eine Führung eines Bediener/Änderungslogbuch hinzu.

Sowas nennt man Event Sourcing.

Bzgl. Logging verwendet man aktuell Full Structured Logging zB via SeriLog.
Logging und Event Sourcing sind aber zwei paar Stiefel - und eigentlich ein Kernelement jeder modernen Anwendung.

Beides aber wiederum haben mit Syncing zweiter Datentöpfe (nur) wenig zutun.

Ich werde aber nicht mal so eben alles Umstellen können.
In wie fern hilft mir Full Structured Logging von SeriLog oder auch von nlog für das Benutezrlogbuch weiter?

Ich werde mir es mir aber nochmal näher ansehen.

Danke.

In wie fern hilft mir Full Structured Logging von SeriLog oder auch von nlog für das Benutezrlogbuch weiter?

Gar nicht.

Ich wollte damit suggerieren, dass ein Anwendungslogging im Sinne von Tracing/Application Insights nichts mit einem Event Sourcing zutun hat - und auch getrennt werden sollte.

Ich werde aber nicht mal so eben alles Umstellen können.

Event Sourcing, was Du möchtest, hat aber leider einen relativ hohen Umsetzungsaufwand.
Ein Datumsfeld in einer Spalte wird Dich hier ja allein nicht weiter bringen.

Noch ein paar Zusatzinformationen und mein Ansatz für eine Umsetzung.

Auf jeder Seite gibt es aktuelle eine Tabelle zum Beispiel für die Mitarbeiter mit den folgenden Spalten* ID

• Name
• EMail
• ...

Wenn auf einer Seite die EMail geändert wurde, weiß ich ja nicht was die "gültige".
Oder es erfolgt auf beiden Seite eine Änderung, sofern die selbe Änderung vorgenommen wurde, ist ja auch weiter nichts zu tun.
Wurde auf beiden Seiten unterschiedliche Änderungen vorgenommen, welche ist jetzt die gültige?

Jetzt ist meine Idee zu jeder Spalte eine weitere hinzuzufügen, welche aussagt wann die letzte Änderung erfolgt ist.* ID

• Name
• EMail
• EMailTimestamp
• ...

Anhand dieses Timestamp kann ich entscheiden, welches die gültige ist.
D.h. die letzte Änderung hat gewonnen.

Erfolge auf einer Seite eine Änderung, muss dieses durch die Synchronisierung zu der anderen Seite "übertragen" werden.
Und dort auch die Änderung ins Bedienerlogbuch eingetragen werden.
Es reicht nicht zu sagen das sich der Wert von A in B geändert hat, sondern es muss auch erfasst werden wer die Änderung gemacht hat.
Hat BedienerA eine Änderung vorgenommen, muss im Bedienerlogbuch auf der anderen Seite auch zusehen sein das BedienerA dieses vorgenommen hat.
Auf beiden Seiten sind die gleichen Bediener vorhanden.

Aber wo ich jetzt diese Zeile schreiben, fällt mir auf das die Timestamp nicht reicht.
An dieser kann ich ja nur entscheiden, was der gültige Wert ist.
Für das Bedienerlogbuch bräuchte ich noche eine Spalte für die UserID also z.B. EMailUserID.

Alternativ müssen die Änderungen in einer weiteren Tabelle geschrieben werden, welche als Basis für die Synchronisierung hergenommen wird.

Für diesen Fall gibt es History Tabellen, sowas in die eigentliche Tabelle zurühren ist absoluter Unfug.
Spar dir den ganzen Unsinn und lass es die Datenbank machen.

Diese erledigt die Replikation dann über das Transaktionslog, was du nur mit extremen Aufwand nachbilden kannst.

Du machst dir schon bei einer Tabelle zusätzlichen Aufwand, der absolut unnötig und Zeitaufwändig ist.
Gerade zum Datenabgleich auf Datenbankebene ist die Datenbank selbst zuständig hiersollte man nicht auf Anwendungsebene der Datenbank in ihre Aufgaben reinkrätschen.
Dies manuell nachbauen zu wollen ist schon deshalb nicht sinnvoll, weil du gar nicht wissen kannst welcher Datensatz beim Neustart des ursprünglichen Masters zum Master oder Slave gehört und somit in die richtige Richtung gepliziert werden muss.

Gerade hier kann die Datenbank durch einfache Transaktionslog Abgleich die Daten konsistent halten und sämtliche Transaktionen in beide Richtungen komplett abgleichen.

So bastelst du dir eine Lösung die den Aufwand nicht rechtfertigt und das nur bei einer Tabelle.
Das würde dir jeder der sich ausgiebig mit Datenbank beschäftigt, was hier einige Leute sein dürften, raten.

T-Virus

Das eine Replikation per Datenbank geht ist mir bekannt.
Aber hierfür muss doch auf beiden Seiten das gleiche DB-System, Version und noch das gleiche Schema sein. Das kann nicht vorausgesetzt werden.

Weiterhin soll und darf nicht die ganze Datenbank repliziert werden. Es wird nur eine Teilmenge der Daten synchronisiert.

Hallo,

leg dir doch eigene Synchronisationstabellen an, die nur die Daten enthalten, die in das andere System übertragen werden müssen.

glandorf

Sicherlich gibt es Werkzeuge hierfür. Wird eigentlich das Microsoft Sync Framework noch gepflegt bzw. gibt es Nachfolger?

Ich mag die Replizierung von CouchDB (und PouchDB) sehr.
Damit sind auch bidirektionale sowie Master-Master (n Nodes) möglich.

Die Problematik des "gleichen Schemas" fällt durch die NoSQL-Thematik (Dokumentenorientierte DB) weg.

NoSQL-Datenbanken lösen das Schema-Problem nicht gänzlich; sie vereinfachen lediglich die Migration durch schemalosen Inhalt.
Ein Schema - wenn auch nur per Definition - hast Du trotzdem, denn Du willst ja wissen, welche "Typen" in einer Collection liegen. Hellsehen kann ja keine DB-Schnittstelle.

Bin ebenfalls ein großer Befürworter von NoSQL-Datenbanken; vielen ist aber die Consistency wichtiger als die Availability im Sinne des CAP-Theorem - und da fällt dann CouchDB halt raus.
CouchDB lohnt sich eigentlich fast nur, wenn man eine Master-Master statt Master-Slave Replikation hat; und Master-Master ist hier ja nicht der Fall.

CouchDB ist aber eben noch wegen PouchDB beliebt, weil es im Prinzip schmutzig aber einfach ein Sync zwischen bei Apps und WebApps ermöglicht.
Seh ich hier jetzt auch weniger 😉

CouchDB ist aber eben noch wegen PouchDB beliebt, weil es im Prinzip schmutzig aber einfach ein Sync zwischen bei Apps und WebApps ermöglicht.
Seh ich hier jetzt auch weniger 😉

Die Sync-Funktionalität von CouchDB finde ich nicht "Schumtzig" sondern eher sehr elegant. Aber da kann man natürlich verschiedene Meinungen haben.

Insbesondere die Revisions und der Change-Feed unterstützen bei einigen der Anforderungen ("Bedienerlogbuch").
Entsprechend dieser Funktionalität wollte ich CouchDB dem OP bekannt machen. Ob es passt wird er dann entscheiden.