nicht angemeldet
Hallo,
Vorab, ich habe versucht das so zu entwickeln, das man es in bestehende Systeme einbinden kann, ohne in Abfragen eingreifen zu müssen. Und ich denke ich bin auf dem richtigen Weg das das auch gelingen sollte.
Und ich habe die Synchronisation zu einem BEstehenden Single-Db-System dazu entwickelt. Auf den Remotesystemen hatte ich Spielraum.
BTW: deshalb hatte ich auhc zwei ID-Felder bei den Remotesystemen.
Ja, aber da bekome ich mit meinem obigen Vorhaben probleme, ich müsste sämtliche Abfragen, Links, Parameter... verändern, da ich keien eindeutige ID mehr habe. Wenn aber alle Datensätze überall eindeutig über eine Id definiert sind, wird das erheblich einfacher, und wenn dann noch die Tabellen komplett gleich sind, dann befindet man sich im 7. Synchronistaions-Himmel, wobei ich weiß das man das eigentlich von eienr anderen Seite her angehen sollte, aber ich weiß schon was ich tue wenn ich das für eine Anwendung implementiere.
Nur... Wenn Du Beziehungen zwischen den Tabellen hast, mußt Du diese ja immer wieder korrigieren. D.h. Wenn Du die Id umschreibst, müssen, alle Datensätze anderer Tabellen, die sich darauf beziehen, entsprechend geändert werden. Das bedeute wesentlcih mehr Aufwand bei dr Synchronisationsschnittstelle. Das war auch die Schwachstelle bei der zwei-ID-Lösung. Die nächste zentrale Datenbank wird eine Herkunfts-ID aufweisen.
Vielleicht trifft Dich heute dieses Problem noch nicht, spätestens wenn Du mehrere Tabellen synchronisierst, die miteinander in Bezug stehen, wird es haarig.
Ich verwende zwei Methoden, um geänderte Daten festzustellen. Am zentralen Server wird die Timestamp verwendet, und die Remotedatenbanken verwenden ein Änderungsflag.
Gut, das heißt Du hast verschieden Tabellen auf dem Client und dem Master, oder zumindest entsprechende verschiedene Abfragen in der Anwendung, oder? Das will ich nicht!
Ja, wie gesagt, ich hatte Spielraum.
Der Grund dafür ist, daß ich mich nicht mit den wahrscheinlcih sicherlich vorhandenen Unterschieden der Systemzeiten auseinandersetzen will.
Wieso? Das ist doch das einfachste! Du loggst auf beiden Systemen nicht eine Zeit sondern die jeweils eigene System-Zeit und ziehst die dann bei Vergleichen heran!
Und schon wird's kompliziert. Welche Zeit bestimmt Deinen letzten Synchronisationszeitpunkt? Die der zentralen Datenbank, oder die des Remotesystems? oder merkst Du Dir beide Zeiten.
Naja, eine Lösung gäbe es ja dafür, XNTP. Das wäre sowieso das beste, allerdings mußt Du dann auch sicher sein, daß der immer funktioniert. Ich hatte anfangs schon Problem, wenn der Rechner auf dem die Sync-Engine läuft eine andere Zeit gegenüber dem Datenbanksystem hat.
3.) diese Daten werden in ein neutrales Format (Text-Dateien) gebracht und an den Server übertragen.
vielleicht nicht neutral, aber SQL-Statements finde ich besser
Das bedeutet aber, daß eines der Systeme etwas über das andere wissen muß. Ich habe es dagegen so ausgelegt, daß immer nur das System, auf dem der aktuelle Vorgang läuft, seine eigene Datenbank kennen muß.
4.) Als Meta-Information wird noch die Remotehost-ID und der Zeitpunkt der letzten Synchronisation übertragen.
der Remote-Host wird auch übertragen, der letzte Sync Timestamp wird aber aus der jeweils eigenen speziellen sync-Tabelle ausgelesen, dem client entsprechend
Ich habe es vorgezogen, daß das Remotesystem besser alles über den aktuellen Zustanad weiß, und daß das dem Zentralsystem ziemlich egal sien kann. Im zweifelsfall wurde die Remotedatenbank einfach durch einenen Dump neu angelegt, wobei dann dort auch der Sync-Timestamp eingetragen wurde.
5.) Am Server wird zuerst einmal der aktuelle Timestamp ermittelt. Dieser Wert dient einerseits dazu, daß nur Daten, die bis zu diesem Wert in der Datenbank sind berücksichtigt werden, zum anderen wird er auch zurück an das Remotesystem übertragen, wo für die nächste Synchronisation als 'letzter Synchronisationszeitpunkt' abgelegt wird.
ich muß gestehen, das meine Timestamps nicht immer 100% gleich sind, sollt eich vielleicht mal drüber nachdenken.
Wie gesagt, das Remotesystem sollte von sich alles wissen. Daß ich den aktuellen Timestamp quasi als oberer Grenze eingezogen habe, liegt daran, daß bei mir die Synchronisation jederzeit stattfinden konnte, meist wirklich auch dann, wenn auf dem zentralsystem Datenmanipulationen durchgeführt werden, in der Geschäftszeit sozusagen.
6.) dann wird jeder übertragene Datensatz des Remotesyystems eingepflegt. Das passiert so, daß zuerst anhand der ID (+Herkunftskennung) geprüft wird, ob er schon vrhanden ist. Wenn nicht, dann wird ein Insert geamcht, ansonst ein Update. Für die Bestätigung werden nun für jeden Datensatz eine Rückmeldung generiert, die praktisch dem Übertragungs-Datensatzformat entspricht.
Das wird bei mir halt schon auf dem Client system ermittelt und entsprechend vorher generiert und dann auf dem Master ausgeführt.
Wobei, wie ich schon erwähnte, die Clientseite einiges über die Zentrale Datenbank wissen muß. Konfilktmanagment wird dadurch enorm erschwert.
7.) Ist das erledigt, werden am Server nun alle Datensätze ausgelesen, die zwischen dem letzten Synchronisationstzeitpunkt (das ist der vom Remotesystem übertragene Zeitpunkt) und dem unter 5.) ermittelten Timestamp geändert wurden. Diese Daten werde auch in das Übertragungs-Text-Format übergeführt.
Das habe ich auch so vor, halt mit der unterscheidung ob Update oder Insert, anhand einer StatusID, odr Flag oder wie auch immer Du das nennst, und der HerkuunftsID und dem Timestamp. Aus den Daten kann ich schon vor der Übertragung ermittlen, was für ein Statement ich generieren muß.
Hier wird es wieder umgekehrt. Das Zentrale System muß viel über das Remotesystem wissen, auhc das empfinde ich als enormen Nachteil.
Warum hast Du kein CSV-Format gewählt?
Weil das unflexibler ist. Vielleicht soll ich noch etwas wieter ausholen. Ich habe bewußt eingeplant, daß sich die Datenstrukturen auf den Systemen unterscheiden können. So war es von haus aus klar, daß die Remotesysteme nur mit einem Subset an Daten auskommen müssen. Es war sogar so, daß sie nicht einmal die selbe Tabellenstruktur hatten. Außerdem wurde im Laufe der Zeit am Remotesystem Erweiterungen durchgeführt, die ich natürlcih auch abdecken wollte. Dabei kamen bei beiden Systemen sowieso unterschiedliche DBMS zum Einsatz.
Also ich mache das ganz anders, ich generiere auf dem Remote-Syestem Insert- und Update-Statements, die ich urlencode und mit curl an den Master schicke, dann mit PHP an die Standardeingabe für das mysql-Kommandozeilen-Tool übergebe. Das funktioniert sehr gut und ist darüberhinaus sehr schnell, wobei das Nadelöhr bei mir eher in der Übertragungszeit(trotz DSL) liegt, ich habe mit 120KB Daten gestestet, das dauert schon 10 Sekunden, vom Starten von Curl bis zur Erfolgsmeldung das die Daten am Server angekommen sind, sonst mache ich nichts!
Wobei ich denke, daß die Statements vom Volumen her um nichts kleiner sind als 'meine' Daten, eher etwas mehr. Noch etwas, leere Felder werden bei mir natürlich nicht übertragen, warum auch.
Was mir noch gar nicht gut gefällt, ich schreibe die Inserts ohne ID in die Master-Datenbank, damit die hier "globale" ID bekommen. Um diese ID wieder zurückzuermitteln, mache ich das zur Zeit so, das ich die Datensätze (alle die neuer sind als der Startzeitpunkt der Synchronisation)komplett mit mysqldump auslese und wieder zurückübertrage, also extremst viel overhead, das sollte ich vielleicht mal ändern.
Ja, deshalb siehe meine Lösung, da wird eigentlich nur das notwendigst geschickt, ohne zuviel Flexibilität zu verlieren.
Sowas brauche ich auch noch, aber erstmal soll die Synchronisation so funktionieren, mal gucken wie ich das am besten integrieren kann.
Bei so einem Vorhaben solltest Du wirklich alles zumindest woerit überlegen, daß Du Dir mit der Lösung nicht zu viele Wege verbbaust. Ich bin zwar ans sich auch nicht dafür, gleich von Anfang an alle möglichen Eventualitäten einzubauen, nur das grundlegende Modell sollte robust genug sein, auch bei Erweiterungen noch zu funktionieren.
Ich denke zwar nicht, dßa meine Lösung unbedingt die beste ist, vor allem da ich doch einiges an Rahmenbedingungen hatte, die andere Wege von vorn herein ausgeschlossen haben. Trotzdem denke ich, daß da einiges auhc für Dein vorhaben drin ist. Wir werden ja sehen, was Du da letztendlich ausbrütest;-)
Grüße
Klaus