Nehmen wir als Beispiel das Lagerhaussystem eines Produzenten für Sportartikel. Es gibt eine Tabelle mit Produktinformationen, in der eine Quantity-Spalte die Anzahl der einzelnen Produkte auf Lager enthält. Eine Aktualisierung in dieser Spalte würde typischerweise die Menge an Lagergütern verringern oder sie im Falle einer frischen Lieferung erhöhen.
Ein Handelsvertreter, der mit einer entfernten Datenbank arbeitet, gibt eine Bestellung ein, wodurch der Bestand an bestimmten T-Shirts von 28 auf 23, also um fünf, verringert wird. Bevor diese Aktualisierung an die konsolidierte Datenbank repliziert wird, erhält ein anderer Handelsvertreter 40 T-Shirts retourniert. Dieser Handelsvertreter gibt diese Rückgabe in seine entfernte Datenbank ein und repliziert die Änderungen an die konsolidierte Datenbank im Lagerhaus, wodurch 40 der Quantity-Spalte hinzugefügt werden, was 68 ergibt.
Der Lagerhaus-Eintrag wird der Datenbank hinzugefügt. Die Quantity-Spalte zeigt, dass es nun 68 T-Shirts auf Lager gibt. Wenn die Aktualisierung des ersten Handelsvertreters eintrifft, entsteht ein Konflikt: SQL Anywhere erkennt, dass die Aktualisierung von 28 auf 23 lautet, der aktuelle Wert der Spalte jedoch 68 beträgt.
Standardmäßig setzt sich die aktuellere Aktualisierung durch, sodass die Inventargröße fälschlicherweise auf 23 gesetzt wird.
In diesem Fall sollte der Konflikt durch das Zusammenzählen der Änderungen in der Inventarspalte gelöst werden, um das Endergebnis zu berechnen, damit der endgültige Wert von 63 in die Datenbank eingetragen wird.
Ein geeigneter RESOLVE UPDATE-Trigger in dieser Situation würde die Veränderungen aus den zwei Aktualisierungen addieren. Zum Beispiel:
CREATE TRIGGER resolve_quantity RESOLVE UPDATE OF Quantity ON "DBA".Products REFERENCING OLD AS old_name NEW AS new_name REMOTE AS remote_name FOR EACH ROW BEGIN SET new_name.Quantity = new_name.Quantity + old_name.Quantity - remote_name.Quantity END; |
Dieser Trigger addiert die Differenz zwischen dem alten Wert in der konsolidierten Datenbank (68) und dem alten Wert in der entfernten Datenbank, als die ursprüngliche UPDATE-Anweisung ausgeführt wurde (28), zu einem neuen Wert, der versendet wird, bevor die UPDATE-Anweisung implementiert wird. Daher wird new_name.Quantity 63 (= 23 + 68 - 28), und dieser Wert wird in die Quantity-Spalte eingegeben.
Die Konsistenz wird in der entfernten Datenbank folgendermaßen gewahrt:
Die ursprüngliche entfernte UPDATE-Anweisung änderte den Wert von 28 auf 23.
Der Eintrag des Lagerhauses wird in die entfernte Datenbank repliziert, was allerdings scheitert, da der alte Wert nicht der ist, der erwartet wurde.
Die Änderungen durch den RESOLVE UPDATE-Trigger werden in die entfernte Datenbank repliziert.
Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |