-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 04 September 2002 19:10, Josef Spillner wrote:
On Wednesday 04 September 2002 10:16, Stefan Lagotzki wrote:
es war nur ein Uebungsbeispiel. Mir war klar, dass es IRL anders gemacht wird. Aber wenn es nur die Kontenverwaltung auf einem Rechner mit einem User waere, dann wuerde es funktionieren(??).
Transaktionen decken den (seltenen) Fall ab, daß inmitten einer solchen Abfrage z.B. der Strom ausfällt oder eine sonstige Unterbrechung geschieht. Egal, ob nun zuerst in A geschrieben und dann in B gelöscht wird, oder umgekehrt, es kommt immer zu Inkonistenzen (fehlende bzw. doppelte Einträge). Das ist sogar fast 1:1 mit Journaling Dateisystemen zu vergleichen: Auch dort wird ein Log geführt, welches im Bedarfsfall dazu dient, einen Urzustand wieder herzustellen.
Erzaehl das nicht deinem DB-Prof. der wird Dich dafuer durchfallen lassen!
Fuer dieses Feature ist das Transaction-Log zustaendig (WAL bei PgSQL).
Transaktionen sind dazu da Nutzer/Prozesse voneinander zu isolieren, also zu verhindern, dass unterschiedliche Prozesse widerspruechliche Daten erzeugen. Es gibt da ein ganzes Buendel von Szenarien:
Lost-write: A/B lesen A/B rechnen A schreibt B schreibt (ueberschreibt das Ergebnis von A)
inconsistent write A liest B liest B schreibt A schreibt Ergebnisse, die auf Grundlage veralteter Daten erstellt wurden
usw.
http://openacs.org/philosophy/why-not-mysql.html zitiert das ACID Prinzip, der Rest ist Flame...
In MySQL gibt es auch Transaktionen, allerdings werden die erst ab Version 4 standardmäßig mit dabei sein, und die sollte man für wichtige Daten noch nicht einsetzen.
Wahrscheinlich irre ich mich: MySQL macht Transaktionen ohne Rollback, das ist keine sehr gute Idee...
Ausserdem gilt diese Implementation noch als recht wacklig.
Konrad
- -- Never shown Star Trek episodes #25: Janeway: "Ok, now. What do you want on the bridge young man?" Pizzaboy: "Who of you ordered this pizza?" Paris: "Ooops."