Reiehnfolge Einzelschritte bei Update in Access-Jet-SQL

muemmel

Hi,

gibt es in SQL eine vorgegebene Reiehnfolge, wie die Einzelschritte einer Update-Anweisung ausgeführt werden.
Beispiel:

Update Tabelle set
Spalte_1 = 3,
Spalte_2 = Spalte_1 + 5

Kann ich mich darauf verlassen, dass in der Reihenfolge wie es hingeschrieben wird immer erst die obere Zeile und danach die untere Zeile abgearbeitet wird, oder guckt SQL da nach Abhängigkeiten und weist erst die Ursprungsdaten zu oder ist das zufallsabhängig?
Vielen Dank im voraus.

Gruß Mümmel

tenim

gelöscht, hatte deine frage falsch verstanden.

hustbaer

Ich würde davon ausgehen dass es auf jeden Fall deterministisch ist. Und dass es nicht davon abhängt ob man eine Spalte für die Berechnung einer anderen verwendet.

Probier mal
`update x set a = 1, b = 1;

update x set a = b + 1, b = a + 1;`

Mein 1. Tip wäre dass die gelesenen Werte alle unabhängig von den neuen Werten sind. Also in diesem Beispiel Ergebnis a = 2, b = 2.

Mein 2. Tip wäre dass die Zuweisungen in genau der Reihenfolge durchgeführt werden wie man sie schreibt. Also hier dann a = 2, b = 3.

tenim

das ergebnis ist immer dasselbe, egal in welcher reihenfolge die anweisungen ausgeführt werden. einfach, weil er die originaldsten der tabelle nimmt und erst dann die anweisung darauf anwendet. innerhalb des update-befehles arbeitet er nicht mit zwischenergebnissen, die aufgrund vorheriger teilausführungen des befehls endstanden sind. er nimmt immer die ursprungsdaten.

so, das müsste jetzt stimmen.

muemmel

Hi,

vielen Dank für die Hinweise. Das mit den Originaldaten scheint wirklich so zu sein.
Bleibt nichts anderes übrig, als ein Wert mehrmals gebraucht wird, den jedesmal neu zu berechnen, oder die Zuweisungen in Einzelschritte aufzuteilen. Aber anscheinend vermag der SQL-Interpreter m,ehrfache Berechnungen der gleichen Sache mit identischer Syntax doch recht gut zu erkennen und durch einmalige Berechnung zu ersetzen, denn ich hab keine merkbaren Performance-Einbußen festgestellt.
Was solls, für mehrfaches Einsetzen des gleichen Ausdrucks gibts Copy und Paste und die größte Verzögerung sitzt sowieso immer 30 cm vor dem Bildschirm.

Gruß Mümmel

hustbaer

Oft bietet es sich an die Berechnung in der Applikation zu machen, und dann nur mehr das fertige Ergebnis an die DB zu schicken.

Geht bei Updates natürlich nur wenn das Ergebnis wie in deinem Beispiel* nicht von Daten in der Zeile abhängt. Oder man eine längere Transaktion mit SELECT + UPDATE verwendet - was ich aber gerne vermeide wenn's nicht nötig ist. (z.B. auch weil es DBs gibt die atomare Updates ohne Transaktionen können.)

Und ansonsten wirst du den Unterschied bei 'nem Update wohl kaum spüren, selbst wenn ein paar arithmetische Operationen doppelt oder dreifach gemacht werden. So ziemlich jeder andere Teil der zur Ausführung eines Update nötig ist wird da wesentlich länger dauern (kompilieren, Query Plan erstellen, IO, ...).

* EDIT:
So wie du dein Beispiel ausgeführt haben wolltest meine ich natürlich. Dass es in Wirklichkeit eben schon von den Daten in der Zeile abhängt wurde ja bereits geklärt

muemmel

Hi Hustbaer,

die Lösung, bestimmte Berechnungen in der Applikation zu machen ist normalerweise der Weg des geringsten Widerstandes. Aber damit ist der Rechenalgorithmus fest in der Anwendung verdratet.
Bei mir kommt es jedoch darauf an, dass für die Nutzer im jeweiligen Bundesland unabhängig von mir Anpassungen an die dort geltenden Bestimmungen von den dortigen Fachkräften vorgenommen werden können. Daher habe ich die gesamte Berechnung in einzelne SQL Befehle in eine Datenbanktabelle in Memofelder ausgelagert, wo für jeden Berechnungsschritt die Befehle der entsprechenden Befehls-Gruppennummer in der Reihenfolge der einzelnen Befehlsnummern abgearbeitet werden. Lediglich die zu verarbeitenden Datensätze werden dabei durch fest vorgegebene Parameter spezifiziert.

Gruß Mümmel