zu Bsp 1
Eine Transaktion an sich frisst kein Brot (tatsächlich frisst sie doch welches, aber unsereiner wäre mit dem bisschen auf Extremdiät)
Zum Ausprobieren eignen sich die berühmten "ganz vielen Datensätze", die man importieren muss.
Macht man ein Commit per
SQL nach jedem einzeln Insert Statement, dauert es etwas länger, als wenn man bspw. nur alle 1000 oder 10000 Datensätze ein Commit macht. (Am besten man macht nur eins, am Ende)
Unabhängig von Art und Programmierung des Clients, für den Server ist sowieso alles immer in einem Transaktionskontext. Das läuft ständig mit.
zu Bsp 2
Die Konfiguration, die nur der Client kennt (und ich nehme mal an, gemeint ist: per Client Transaktion erzwingt), ist ein fachlicher, logischer Zusammenhang in dem eine Datenverarbeitung ablaufen soll. Das ist erstmal okay, es produziert aber overhead, den man gerne vermeiden will.
Nehmen wir SP1> SP3 und stellen uns vor, es sei das Update und Insertstatement aus dem Thread hier. Natürlich soll das in einer Transaktion laufen, das eine ohne das andere macht keinen Sinn.
Dazu kann ich nun eine Clienttranskation nehmen, die das ganze "aus der Ferne" aufruft und "künstlich" kapselt. Fall erledigt, ich muss mich aber auf die Implementierung und Nachteile von Clienttransaktionen verlassen (hängt von RDBMS, Client und Compos ab)
Ich kann aber auch einen anonymen Block drum legen und das vom Client als ein einziges Statement auf dem Server ausführen lassen. Es ist damit automatisch eine (1, EINE) Transaktion.
Für die 2. Methode zahle ich idR. einen geringeren Preis, weil der Server selbst besser und schneller arbeitet, als die zusätzlichen Module im Client.
Zitat:
Woher soll die
DB wissen, dass alles in einer Transaktion laufen soll.
Eben, sie weiß es nicht, außer:
ich mache daraus eine eigene SP oder einen anonymen Block, fertig.