Synchronisation von Daten

[Roger]

moin!

die synchronisation von daten beschäftigt mich schon seit ner ganzen weile. wie funktioniert das? woher weiss die master-datenbank, was sie von der client-db abgleichen soll? sicherlich ist zum beispiel bei einem kalender (mein poket pc und outlook waren der ausschlaggebende grund) ein neues datum, was ich angelegt habe leicht zu synchronisieren. aber woher weiss nun das programm, dass der termin auf dem einen gerät angelegt und nicht auf dem anderen  gelöscht wurde?
ich kann mir das nur so vorstellen, dass es eine extra db gibt, die von allen feldern das lastmodyfied-datum speichert. scheint mir aber nicht so die praktikabelste lösung zu sein. denn bei nem hohen datenaufkommen, ist diese db wohl auch ziemlich schnell ausgereizt...

gru.
roger.

[Sven Rautenberg]

Moin!

die synchronisation von daten beschäftigt mich schon seit ner ganzen weile. wie funktioniert das? woher weiss die master-datenbank, was sie von der client-db abgleichen soll? sicherlich ist zum beispiel bei einem kalender (mein poket pc und outlook waren der ausschlaggebende grund) ein neues datum, was ich angelegt habe leicht zu synchronisieren. aber woher weiss nun das programm, dass der termin auf dem einen gerät angelegt und nicht auf dem anderen  gelöscht wurde?

In Abhängigkeit von den typischen Datenbewegungen (gehts zwingend nur in eine Richtung, oder in beide?) und den Änderungswahrscheinlichkeiten (wird immer an beiden Stellen alles gleichzeitig geändert, oder üblicherweise nur wenig geändert, und wenn dann auch nur zwischen zwei Synchronisationen an einer Stelle - oder nicht an denselben Datensätzen) kann man gewisse Hilfsdaten verwenden.

Am Beispiel "Adressdatensätze":

Zusätzlich zu den Daten gibts ein Feld "geändert" als true/false-Flag. Wird ein Datensatz neu angelegt oder verändert, wird das Feld auf true gesetzt. Wird es zur Gegenstelle synchronisiert, dann wird es auf false gesetzt.

Neue Datensätze, die nur auf der einen Datenbank auftauchen, werden beim Sync dann immer anhand dieses Flags erkannt und übertragen. Gelöschte Datensätze haben genau wie neue Datensätze kein Gegenstück - der Unterschied ist, dass neue Datensätze als "geändert" gekennzeichnet sind, und (noch nicht) gelöschte Datensätze als "unverändert".

Wenn man das ganze auch noch mit mehreren Datenstationen (ein PDA an mehreren unabhängigen Computern) funktionieren soll, dann speichert man zusätzlich noch das Datum der letzten Änderung mit ab und vergleicht, welcher Datensatz neuer ist.

Was damit allerdings nicht funktioniert: Wenn auf beiden Stationen die gleiche Adresse geändert wird, kann man das mit diesem System nicht feststellen, sondern müßte im Prinzip auf eine Protokollierung sämtlicher Änderungen zurückgehen, die gemacht wurden. Wenn auf dem PDA die Telefonnummer und auf dem PC die Hausnummer geändert wurde, sind das ja im Grundsatz zwei konfliktfreie Änderungen, das Ergebnis sollte ein Datensatz sein, in dem beide Änderungen auftauchen.

Richtig problematisch wird es, wenn auf beiden Stationen dasselbe Feld geändert wurde, wobei Änderungen auf den gleichen Wert immer noch kein Problem darstellen. Unterschiedliche Werte hingegen sind problematisch, also beispielsweise die Telefonnummer einmal auf die neue Zentrale, und einmal auf die Durchwahl. Oder eine neue Nummer ist falsch, die andere richtig. Welche Angabe ist dann als korrekt zu bewerten? Ein Computer kann das nicht entscheiden, weshalb man in der Konzeption solcher Synchronisationen diesen Fall entweder ausschließt (entweder dadurch, dass Änderungen nur an einer zentralen Datenbank vorgenommen werden, oder dass der Änderungswunsch zunächst eine Schreibblockade auf allen angeschlossenen, zu synchronisierenden Stationen erstellen muss, damit niemand anders den Datensatz parallel ändert - mir gefällt der zweite Ansatz allerdings überhaupt nicht), oder im Konfliktfall den Benutzer fragt, welche Information denn jetzt korrekt ist.

Das Problem mit der Nachfrage: Derjenige, der gefragt wird, ist mit so einer Frage unter Umständen überfordert. Er wird in seinem Arbeitsfluß "nur mal eben schnell abgleichen, ich muß gleich weg" unterbrochen und kriegt komplizierte Fragen gestellt, die er mitunter gar nicht so direkt beantworten kann. Beispielsweise wenn der Chef mobil eine Telefonnummer ändert, und die Sekretärin am Rechner ebenfalls, aber eben anders.

- Sven Rautenberg

[Lude]

Hi,

Richtig problematisch wird es, wenn auf beiden Stationen dasselbe Feld geändert wurde, wobei Änderungen auf den gleichen Wert immer noch kein Problem darstellen. Unterschiedliche Werte hingegen sind problematisch, also beispielsweise die Telefonnummer einmal auf die neue Zentrale, und einmal auf die Durchwahl.

kleine Anmerkung: Wenn man mit einem Client auf Serverdaten zugreift, um diese zu laden, zu bearbeiten und danach zurueckzuschreiben, dann haben wir eine aehnliche Situation. Denn es kann ja auch andere Clients geben, die gerade dieselben Daten bearbeiten.

Gruss,
Lude

[Roger]

moin!

kleine Anmerkung: Wenn man mit einem Client auf Serverdaten zugreift, um diese zu laden, zu bearbeiten und danach zurueckzuschreiben, dann haben wir eine aehnliche Situation. Denn es kann ja auch andere Clients geben, die gerade dieselben Daten bearbeiten.

genau dass ist das problem, was ich momentan eigentlich versuche zu lösen. ich habe eine etwas ältere präsenz bei einem kunden, der zu der www-präsenz die daten in 2(!) intranets pflegt.
den bisherigen abgleich hab ich immer mit nem perl script gemacht, was aufgrund der geringen ansammlung der daten nicht allzu kompliziert war. allerdings strebe ich nat. nach einer besseren abgleichmethode, die mir nat. die arbeit abnimmt.

um das mal etwas genauer zu beschreiben:
es existiert ein www-server (www)
ein intranetserver filiale 1 (i_1)
und ein intranetserver filiale 2 (i_2)

es soll generell zum www repliziert werden. nicht umgekehrt.
gepflegt wird dort eine kleine artikel-db. nun kann es eben vorkommen, dass i_1 den gleichen artikel bearbeitet hat wie i_2. klar kann man beim replizieren dann den user fragen, welchen eintrag er denn gern gespeichert haben möchte, aber wie sven schon gesagt hat, verwirrt das nur... und ausserdem ist sowas immer schwer zu automatisieren ;)
in so'nem fall dachte ich an ein log-file. wenn der eintrag aufgrund von div. unstimmigkeiten nicht vollzogen werden konnte, dann wird er extra abgespeichert und von einem admin später dann frei gegeben.
die radikalere variante wäre dann nat. das script nach voreingestellten entscheidungen entscheiden zu lassen. doch ich denke, dass spätestens nach dem ersten verschollenen datensatz das ganze über den haufen geworfen wird :)

das replizieren würde ich dann so lösen, dass der vorhandene eintrag auf sein alter geprüft wird und vielleicht nach der länge (checksumme oder sowas, hat einer ne idee?).

ich weiss nicht.. je länger ich darüber nachdenke, umso komplizierter werden meine gedankengänge...

gruß.
roger.

[Lude]

Hi,

[Erlaeuterungen]
das replizieren würde ich dann so lösen, dass der vorhandene eintrag auf sein alter geprüft wird und vielleicht nach der länge (checksumme oder sowas, hat einer ne idee?).

Ich vermute mal, dass Du an der "evolutionaer" entstandenen, soz. real existierenden Datenhaltung nicht aendern kannst? Das gleiche gilt fuer den Datenzugriff?

Ansonsten muesstest Du hier eine Diskussion ueber Konfliktloesungen bei "ZU Fuss-DB-Replikationen" anfangen. - Ich kenne einen Entwickler, der mal eine Merge-Replikation "zu Fuss" umgesetzt hat. Der hat sich ganz schoen einen abgebrochen (Zitat: 'Was man da alles beachten muss...')

ich weiss nicht.. je länger ich darüber nachdenke, umso komplizierter werden meine gedankengänge...

Also nicht zu viel denken.   ;-)

Gruss,
Lude

[Roger]

moin!

Ich vermute mal, dass Du an der "evolutionaer" entstandenen, soz. real existierenden Datenhaltung nicht aendern kannst? Das gleiche gilt fuer den Datenzugriff?

öhm, wie? was?

"ZU Fuss-DB-Replikationen"

zu fuß?! ich hasse laufen! das weiteste, was ich laufe ist von der zapfsäule bis zur kasse...

gruß.
roger.

[Lude]

Hi,

Ich vermute mal, dass Du an der "evolutionaer" entstandenen, soz. real existierenden Datenhaltung nicht aendern kannst? Das gleiche gilt fuer den Datenzugriff?

öhm, wie? was?

das Daten-Szenario, dass Du hier skizziert hast, scheint mir nicht normal zu sein, d.h. alles ist komplizierter, als es sein koennte, richtig? - Darum habe ich von 'real existierender Datenhaltung' gesprochen (in Anlehnung an die Haltung bei "Honni").

"ZU Fuss-DB-Replikationen"

zu fuß?! ich hasse laufen! das weiteste, was ich laufe ist von der zapfsäule bis zur kasse...

Ich meinte eine handgemachte Merge-Replikation. Nicht-handgemachte Replikationen kommen vom Anbieter des jeweilgen RDB(M)S und sind also vom System bereits unterstuetzt.

Gruss,
Lude

---
"Wer nicht weiss, was er will, will, was er nicht weiss."

[Lude]

Hi,

die synchronisation von daten beschäftigt mich schon seit ner ganzen weile. wie funktioniert das?

meinst Du sowas, wie sog. Offline-Inhalte, die bearbeitet werden und dann wieder in die Hauptdatenhaltung gehen?

woher weiss die master-datenbank, was sie von der client-db abgleichen soll?

Vielleicht wegen der "Zeitschicht" sprich DF mit bestimmter Bedeutung?

ich kann mir das nur so vorstellen, dass es eine extra db gibt, die von allen feldern das lastmodyfied-datum speichert. scheint mir aber nicht so die praktikabelste lösung zu sein. denn bei nem hohen datenaufkommen, ist diese db wohl auch ziemlich schnell ausgereizt...

Aha, Du weisst ja schon fast alles. Leider ist die o.g. Loesung nicht einfacher zu gestalten. Allerdings habe ich nicht verstanden, was eine 'extra db' ist.

Gruss,
Lude

---
"Hier im Forum gibt es nur eine Datenhaltung.   ;-)"