Abgesehen davon, dass auch MySQL bereits seint Versionen 3.x
Transaktionen kann, sieht die Wahrheit doch folgendermaßen aus:
Kein RDBMS kann Transaktionen so, wie man sie gern hätte. Alles was
ich bisher an Transaktions-Lösungen gesehen habe war gestümper -
einfach flach. Das was RDBMS an Transaktionen implementieren dient
doch nur dem Marketing, damit man sich auf die Fahne schreiben kann,
dass man "ES AUCH KANN".
Das Problem liegt hierbei nämlich wie immer zwischen Theorie und
Praxis. Die Datenbanktheoretiker erzaehlen in Besserwissermanie immer
wieder gern was so eine DB alles können muss. Wie wichtig Konsistenz
sei und was weis der Teufel noch. Der Praktiker weiss, dass der
Server 2 GB Speicher hat, die DB 100 GB groß wird und er in der Regel
auf n Mio. Datensaetzen operieren muss.
Und als nächstes weiss der Praktiker, dass er sich das mit den
Transaktionen - erst recht mit verschachtelten - gleich abschminken
kann, vor allem wenn er in/mit einem "Team" aus Anfängern arbeiten
muss die Transaktionen fuer das Allheilmittel halten.
Von daher ist es IMMER wichtig, die Anwendung so zu bauen, dass sie
inkonsistenzen bemerkt und geeignet drauf reagieren kann.
Inkonsistenzen lassen sich nicht wirklich vermeiden. Man muss sie
sehen und korrigieren können.
Die von MySQL haben das früh gewusst und sich nicht in diesem
Transaktionthema "verlieren" müssen - aber auch rechtzeitig gemerkt,
dass die "Experten" ohne nicht leben können.
Transaktionen kann, sieht die Wahrheit doch folgendermaßen aus:
Kein RDBMS kann Transaktionen so, wie man sie gern hätte. Alles was
ich bisher an Transaktions-Lösungen gesehen habe war gestümper -
einfach flach. Das was RDBMS an Transaktionen implementieren dient
doch nur dem Marketing, damit man sich auf die Fahne schreiben kann,
dass man "ES AUCH KANN".
Das Problem liegt hierbei nämlich wie immer zwischen Theorie und
Praxis. Die Datenbanktheoretiker erzaehlen in Besserwissermanie immer
wieder gern was so eine DB alles können muss. Wie wichtig Konsistenz
sei und was weis der Teufel noch. Der Praktiker weiss, dass der
Server 2 GB Speicher hat, die DB 100 GB groß wird und er in der Regel
auf n Mio. Datensaetzen operieren muss.
Und als nächstes weiss der Praktiker, dass er sich das mit den
Transaktionen - erst recht mit verschachtelten - gleich abschminken
kann, vor allem wenn er in/mit einem "Team" aus Anfängern arbeiten
muss die Transaktionen fuer das Allheilmittel halten.
Von daher ist es IMMER wichtig, die Anwendung so zu bauen, dass sie
inkonsistenzen bemerkt und geeignet drauf reagieren kann.
Inkonsistenzen lassen sich nicht wirklich vermeiden. Man muss sie
sehen und korrigieren können.
Die von MySQL haben das früh gewusst und sich nicht in diesem
Transaktionthema "verlieren" müssen - aber auch rechtzeitig gemerkt,
dass die "Experten" ohne nicht leben können.