nicht angemeldet
Hallo,
Grundsätzlich bin ich auch für die Verhältnismäßigkeit zwischen Aufwand und Zweck. Allerdings habe ich die Erfahrung gemacht, daß genau diese Argumentation al Rechtfertigung für"Huschpusch"-Lösungen herangezogen wird. Meist ist etwas mehr Sorgfalt bei jeder Zeile, die man schreibt, schon der richtige Ansatz.
Ja, das stimmt, aber in diesem Fall geht es wohl nicht anders als von mir beschrieben, oder?
Ich denke, daß DU da schon ziemlcih richtig liegst, allerdings ändert das nichts an der Tatsache, daß diese nachträgliche Löscherei ein ganz anderes Problem verschleiert.
Wenn ich Transaktionstabellen verwende, was habe ich dann für einen Vorteil?
Nehmen wir vorliegenden Fall. Da will einer eine PErson löschen, dabei sollten alle verknüpften Einträge aus den anderen Tabellen mit entfernt werden. Dadurch ergibt sich, daß mehr als ein Lösch-Statement abgesetzt werden muß, um diesen Vorgang vollständig durchzuführen.
Wird auch nur eines nicht ausgeführt, da irgendein Fehler aufgetreten ist, dürften alle anderen auch nicht ausgeführt werden, da es sonst zu Inkonsistenzen in der Datenbank kommt. Was nun, wenn es dummerweise nicht das erste Statement ist, daß da abkracht? Dumme Sache, der Datensatz ist weg, unwiderbringlich futsch.
Damit Das nicht passiert, setzt man auf die sog. Transaktionen. Dabei merkt die Datenbank die Aktionen nur vor, für die aktuelle DB_sitzung werden die Daten auch dementsprechend korrigiert verwaltet, und erst wenn alle Statements fehlerfrei ausgeführt wurden, werden die Änderungen auch bestätigt (commit). Sollte ein Fehler aufgetaucht sein, dann wird der Original-Zustand wieder hergestellt, so als ob nie ein Statement abegsetzt wurde (rollback).
In dem hier diskutierten Falle könnte die Anwendung also einmal alle Statements durchführen, wenn es nicht geklappt hat, dem Anwender mitteilen, wo und warum es nicht funktioniert hat, und den Originalzustand wieder herstellen. Es gibt dann nur mehr zwei Möglichkeiten:
Entweder es gibt eine Person mit allfälligen Terminen, oder es gibt weder Person noch die zugehörigen Termine. TErmine, die nicht existierenden PErsonen gehören sind ausgeschlossen.
Und ist der Fall so wahrscheinlich, das wenn ich mehrere Inserts mache, das dann eine davon fehlschlägt und ich alles Rückgängig machen muß?
Öfter als Du jetz annimmst. Es gibt so viele Gründe, warum ein Statement nicht funktioniert, da ist es schon ein Wunder, wenn überhaupt noch was in eine Datenbank kommt *g*.
Grundsätzlich sollten zwei oder mehrere zusammengehörende Statements mittels Transaktionen geschützt werden, sofern die Datenbank das unterstützt. Es kostet zwar etwas an Datenbank-Performance, allerdings macht eine bessere Datenkonsistenz IMHO das wieder locker wett.
Grüße
Klaus