Mailinglisten-Archive |
Andreas Heigl schrieb: > Andi Voss schrieb: > > > > Das selbe Problem wirst du aber auch beim 'Rausschieben' der Daten haben.... Auf die Aktualisierung in dieser Richtung ist ja niemand direkt drauf angewiesen. Wenn im Online-Shop aber jemand einen Artikel anschauen möchte und muss aufgrund der langsamen Datenübertragung längere Wartezeiten in Kauf nehmen, dann wäre das schon blöd. >>Das ganze soll auch bidirektional laufen, also zum Beispiel >>Kundenregistrierungen oder Auftragseingänge im Online-Shop sollen auch >>in der lokal DB eingetragen werden. Also die ganze Geschichte auch >>umgedreht (entfernt nach lokal). Somit ist nicht nur lesender Zugriff >>notwendig. > > Und hier wird das ganze endgültig unsinnig! > Denn wenn jetzt zeitgleich in beiden DBs eine Änderung vorgenommen wird, wer > entscheidet jetzt, welche gilt?? Ich habe gedacht, ich kann das Problem in einer Kurzfassung beschreiben kann...da fehlen aber scheinbar ein paar Infos...mein Fehler ;-) Also es werden nicht alle Tabellen in beide Richtungen geupdatet. In der Tabelle wo zum Beispiel die gesamten Artikeldaten abgelegt sind, wird vom Online-Shop nur lesend zugegriffen. Auf die Tabelle, wo zum Beispiel die Kunden abgelegt sind, wird von beiden Seiten lesend und schreibend zugegriffen. Eintragungen vom Online-Shop erhalten eine Kundennummer ab einem festgelegten Wert (>50000), sodass es mit den lokal angelegten Kunden nicht kollidieren kann (<50000) und erhalten eine Kennzeichnung als Datensatz vom Online-Shop. Dieser wird dann beim nächsten Update von lokal nach entfernt ausgelassen. Sobald lokal Änderungen an solch einem Datensatz(Kunde) getätigt werden, der vom Online-Shop angelegt wurde, verschwindet die Kennzeichnung und der Kunde wird von lokal nach entfernt geupdatet. Und je größer du das zeitfenster des > Abgleiches wählst, desto größer wird die warscheinlichkeit solcher probleme. > Und Dateninkonsistenz ist so ziemlich das schlechteste, was ich mir für so > eine lösung vorstellen kann.... Genau aus diesem Grund hatte ich auch eigentlich an eine sofortige Datenübertragung nach einer Änderung gedacht, aber da stellt sich ja das Problem, dass man nie weiss, wann es eine Änderung gibt. Am besten wäre es, wenn man per TRIGGER aus der Datenbank heraus einen Datensatz in die Shell-Verbindung schieben könnte...aber da hab ich noch keine Lösung gefunden. > Und dann kommst du nicht um eine einzige datenbank (und eventuell andere > DSL-Konditionen) herum... > > Würde ich jetzt mal so behaupten. > > Grüße > > Andreas Danke für Deine Infos. Gruss Andi
php::bar PHP Wiki - Listenarchive