Datenbanksyncronisierung

Hallo Leute!

Ich bräuchte da mal ein paar Ideen von euch. Ich habe folgendes Szenario: Ich möchte meine Webapplikation (zwar in Java mittels Struts, aber das ist egal) an zwei Orten laufen lassen: einmal auf meinem Server und einmal lokal auf meinem Notebook, damit ich die Software auch z.B. in der Firma oder in der Berufsschule nutzen kann. Damit dann nachher in beiden Datenbanken die gleichen Daten liegen, will ich die beiden Datenbanken syncronisieren lassen. Und genau da liegt mein Problem. Die Art der Daten ist sehr unterschiedlich, zum einen sind das reine Adressdaten (also recht wenig Änderungen) und zum anderen sind das Notizen/Mitschriften (sehr hohe Änderung) und Termine (ebenfalls ein hoher Grad an Änderung). Alle Tabelleneinträge sind über eine (für die Tabelle) eindeutige ID gekennzeichnet, aber das kann bei einer einfachen ID-Überprüfung zwischen den Datenbanken natürlich zu Kollisionen führen wenn in beide seit der letzten Syncronisierung Einträge gemacht worden.

Eine Idee von mir war, die Einträge nicht mittels einer Auto Increment ID zu versehen, sondern mit einer GUID. So könnte ich in beiden Datenbanken jeden Eintrag einwandfrei identifizieren kann. Aber ob das der richtige Weg ist weiss ich nicht.

Zum anderen stellt sich mir die Frage wie ich die Änderungen syncronisieren soll. Zum einen aus performancetechnische Sicht: Einfach alle Datensätze durchlaufen und und alle Felder überprüfen erscheint mir zwar der einfachste, aber auch langsamste Weg zu sein. Wäre es sinnvoll, da einen Hashwert über die Spalten (ausser ID und dem Hash selber) anzulegen?
Zum anderen aus organisatorischer Sicht: Das rüberschaufeln von DB A -> B (oder umgekehrt) wenn der Datensatz in der andern nicht existiert ist ja kein Problem. Aber was ist, wenn in beiden Datenbanken der gleiche Eintrag angelegt wird, aber eine unterschiedliche ID (oder GUID) bekommt. Oder wenn an einem syncronisierten Datensatz in beiden Datenbanken unterschiedliche Änderungen vorgenommen werden? Da bleibt doch wohl nur eine Benutzerintervention über, oder?

Ich hoffe ihr könnt mir da ein wenig auf die Sprünge helfen.

Vg,
Johann

Hallo John Doe,

Eine Idee von mir war, die Einträge nicht mittels einer Auto Increment ID zu versehen, sondern mit einer GUID. So könnte ich in beiden Datenbanken jeden Eintrag einwandfrei identifizieren kann. Aber ob das der richtige Weg ist weiss ich nicht.

das ist ok.

Zum anderen stellt sich mir die Frage wie ich die Änderungen syncronisieren soll.

Vernüftig synchronisieren kann man m.E. nur auf zwei Arten:

• Man speichert die Änderungen als Änderungen oder
• man versioniert die Datensätze.

Wenn man das auf die eine oder andere Art macht, ist die Synchronisierung plötzlich ganz einfach.

Egal was man wählt, der Vergleich der Sätze in beiden DBs um Unterschiede festzustellen ist nicht nötig. Man geht einfach die Liste der Änderungen oder die Liste der neuen Versionen durch.

Sicher kann es trotzdem Konflikte geben, die nur der Benutzer lösen kann, aber diese sollten selten sein.

herbivore

Original von herbivore
Vernüftig synchronisieren kann man m.E. nur auf zwei Arten:

• Man speichert die Änderungen als Änderungen oder

[...]

Egal was man wählt, der Vergleich der Sätze in beiden DBs um Unterschiede festzustellen ist nicht nötig. Man geht einfach die Liste der Änderungen oder die Liste der neuen Versionen durch.

Hi,

danke für deine Antwort. Mit anderen Worten eine weitere Tabelle anlegen, in der ich die ID's der jeweils geänderten Datensätze einfüge. Diese Tabelle wird dann bei der Snychronisierung abgearbeitet und fertig?
Ich denke das eine einfache Erfassung der Änderung einfacher zu implementieren ist, als eine Versionierung, oder?

vg,
Johann

Hallo John Doe,

Mit anderen Worten eine weitere Tabelle anlegen, in der ich die ID's der jeweils geänderten Datensätze einfüge. Diese Tabelle wird dann bei der Snychronisierung abgearbeitet und fertig?

Nein, so hatte ich es nicht gemeint. Ich meinte qualifiziert alle Änderungen, also z.B. in Tabelle x hat sich beim Satz mit der ID y das Feld a von b in c geändert. Außerdem noch das Änderungsdatum. Ohne diese Angaben sind Konflikte wesentlich schlechter zu erkennen und zu behandeln. Auch das Löschen und Einfügen muss nachvollziehbar sein.

Die Alternative basiert auf i.d.R. drei Versionen: 1. Original vor der Änderung. 2. Änderung in DB A. Änderung in DB B. Durch den Vergleich der Versionen kann man die Änderungen in der o.g. Qualifizierung ermitteln. Wenn man nicht die Versionen speichert, sollte man die Änderungen speichern, die man aus der Versionen ermitteln könnte.

Wenn du verstehst, worauf ich hinaus will.

Ich denke das eine einfache Erfassung der Änderung einfacher zu implementieren ist, als eine Versionierung, oder?

Eigentlich ist eine Versionierung einfacher zu implementieren, weil man nur in jeder zu versionierenden Tabelle eine Spalte mit der Versionsnummer als Teil der ID einfügen muss. Und wenn man es nicht sowieso hat, vielleicht noch ein Änderungsdatum.

herbivore

Original von herbivore
Wenn du verstehst, worauf ich hinaus will.

Jetzt ja.

Eigentlich ist eine Versionierung einfacher zu implementieren, weil man nur in jeder zu versionierenden Tabelle eine Spalte mit der Versionsnummer als Teil der ID einfügen muss. Und wenn man es nicht sowieso hat, vielleicht noch ein Änderungsdatum.

Ach, so meinst du das. Bei einer Versionierung habe ich eigentlich an eine komplette gedacht. Das quasi bei jeder Änderung (nicht nur zwischen zwei Synchronisierungen) eine Kopie angelegt wird, und die Nummer erhöht wird. So das man zu jedem Zeitpunkt zu jeder Version zurückkehren kann.
Aber ich glaube das würde den Rahmen des Projektes doch erheblich sprengen.

Ich glaube ich werde eine Änderungshistorie einbauen, da ich daran gekoppelt einen Verlauf protokollieren kann.

Danke schonmal.

Johann

Hallo John Doe,

Bei einer Versionierung habe ich eigentlich an eine komplette gedacht. Das quasi bei jeder Änderung (nicht nur zwischen zwei Synchronisierungen) eine Kopie angelegt wird, und die Nummer erhöht wird. So das man zu jedem Zeitpunkt zu jeder Version zurückkehren kann.

hm, so wie du es jetzt schreibst, meinte ich das auch. Durch die Versionnummer in der ID können zu einem Satz beliebig viele Versionen gespeichert werden. Statt einen bestehenden Satz zu überschreiben, sollte immer ein neuer angelegt. Ob man die alten Versionen bei/nach der Synchronisierung löscht, steht ja auf einem anderen Blatt.

Aber ich glaube das würde den Rahmen des Projektes doch erheblich sprengen.

Der Aufwand dafür ist doch minimal.

herbivore