nicht angemeldet
Moin!
So weit, so gut. Ich habe mir jetzt überlegt, ich ziehe nächtlich einfach die Daten aus System A in System B und lasse abrechnen. Jetzt kommt es aber leider vor, dass die Daten nicht korrekt sind und in System B berichtigt werden müssen. Wie schaffe ich es dann, dass die Daten auch in System A übertragen werden, ohne jedesmal ein Live-Update zu machen (teilweise > 3 Sekunden für jeden Datensatz!)?
Zusätzlich sollen Änderungen in System A die Änderungen in System B nicht überschreiben.
Das synchronisieren von Daten zwischen zwei oder mehr Maschinen ist eine durch und durch komplexe Aufgabe, wobei das Problem bösartiger wird, wenn beliebige Aktualisierungsrichtungen möglich sein sollen, und die Sache einfacher wird, wenn man sich in dieser Hinsicht auf eindeutige Richtungen festlegen kann.
Die Sache wird also bedeutend leichter, wenn du deine Datenströme so organisieren könntest, dass diese immer nur in eine Richtung gehen.
Als Beispiel: Auf System A werden neue Adressdaten erfaßt, gehen dann zu System B und werden dort den existierenden hinzugefügt. Dann wird dort was gerechnet, und die Rechnungsdaten gehen dann zurück zu System A. Sowas ließe sich verhältnismäßig simpel programmieren.
Wenn aber die Adresse auf System A nachträglich dort und auch auf System B geändert werden kann, und die Veränderung auf System B wieder zurück nach A soll, dann wird es eben kompliziert. Man kann die Betrachtung dann auf Datensatzebene oder auf Datenfeldebene durchführen (bei Feldbetrachtung multipliziert sich der Aufwand entsprechend):
Ein Datensatz erhält ein Flag "ist synchronisiert", welches auf ja gesetzt wird, wenn ein Abgleich zwischen System A und B erfolgte. Wenn auf einem der beiden Systeme dann eine Veränderung im Datensatz erfolgt, wird auf diesem System das Flag zurück auf nein gesetzt. Bei der nächsten Synchronisierung kommt es dann zu einer von drei Situationen:
1. Beide Systeme haben das Flag gesetzt - nichts wurde geändert.
2. Nur ein System hat das Flag gesetzt - Kopieren der geänderten Daten vom System mit nicht gesetztem Flag.
3. Beide Systeme haben das Flag nicht gesetzt - beide Datensätze wurden parallel geändert, dieser Konflikt muß manuell behoben werden.
Fall 3 ist etwas erleichtert, wenn man nicht den kompletten Datensatz betrachtet, sondern die sync-Flags für jedes Datenfeld vorhält - dann werden die Fälle vermieden, bei denen auf System A die Postleitzahl und auf System B die Telefonnummer geändert wurde. Trotzdem gibt es immer noch die Fälle, bei denen parallel die Postleitzahl geändert wurde.
Wenn beide geänderten Felder den gleichen Inhalt haben, ist das Problem auch leicht gelöst: Es gibt dann doch keinen Konflikt.
Was aber, wenn die zuerst eingetragene PLZ "11111" lautet, und sie auf System A zu "22222" und auf System B zu "33333" geändert wird? Welche Angabe ist jetzt richtig und darf überleben? Oder (wenn es nicht unbedingt um Postleitzahlen geht) ist vielleicht auch ein Mittelwert korrekt, oder sonst ein zu berechnender Wert (beispielsweise wenn es um Bestellungen geht, und man die Anzahl addieren sollte).
In solchen Fällen muß immer manuell nachgearbeitet werden. Wobei in dem skizzierten System folgende Katastrophe passiert ist: Weder auf System A noch auf System B ist die original eingegebene Postleitzahl mehr gespeichert - diese wäre vielleicht für die Entscheidung, welche Postleitzahl denn tatsächlich gültig ist, nicht unwichtig.
Die einzig plausible Möglichkeit, die ein Kollege vorschlug, passt uns allen nicht wirklich. Man müsste für jedes Feld einen eigenen Timestamp haben, damit man die Änderungen nachvollziehen kann.
Ob du nun Timestamps oder nur Flags benutzt, ist für das Ergebnis recht egal: Es ist in jedem Fall möglich, dass parallel dasselbe geändert wird, und dir deshalb deine Synchronisation zusammenbricht. Mit Timestamps hast du die Möglichkeit, die zwei geänderten Felder zeitlich zu sortieren, also eine frühere und eine spätere Änderung herauszufinden - und dann beispielsweise zu entscheiden, dass immer die spätere Änderung gelten soll. Aber mit welcher Berechtigung eigentlich?
Die Alternative zur freien, ungehinderten Bearbeitung auf A und B wäre, dass eine Station, auf der Änderungen durchgeführt werden sollen, eine Sperre auf der anderen Station setzt, die Änderungen dort verhindert. Dies muß aber zwingend "live" geschehen, und die Sperren müssen natürlich auch wieder zurückgesetzt werden. Außerdem bedeutet es, dass beide Systeme sich jeweils gegenseitig erreichen müssen.
Und wenn man schon live Sperren setzen muß, kann man eigentlich auch gleich direkt Datensätze austauschen und eine zentralisierte Datenbank benutzen. :)
- Sven Rautenberg