SQL Schreibvorgänge erst mal simulieren?

JardelBenz

Banned
Registriert
Dez. 2016
Beiträge
821
Wenn ich z.B. den Befehl "Update" ausführe, dann kommt am Ende ja die Meldung, wieviele Datensätze geändert wurden.

Kann ich den Befehl zuerst auch nur mal simulieren?

Also dass nicht gleich geschrieben wird, sondern mir nur angezeigt wird, wieviele Datensätze geändert werden würden?
 
Ja, indem du dein Update in ein Select umwandelst.

Willst du also

UPDATE TABLE SET COLUMN = 1 WHERE COLUMN = 2

machen, machst du einfach:

SELECT COUNT(*) FROM TABLE WHERE COLUMN = 2
 
Transaction Klammer nutzen ... -> klick.

Beispiel
Code:
CREATE TABLE ValueTable (id int);  
BEGIN TRANSACTION;  
       INSERT INTO ValueTable VALUES(1);  
       INSERT INTO ValueTable VALUES(2);  
ROLLBACK;
 
@_killy_

funktioniert zwar, ist aber in dieser Fragestellung eine schlechte Idee:

1) Er will ein Update und kein Insert ausführen, wenn du das in eine Transaction verpackst lockst du die Datensätze exclusiv für andere User bis zum commit oder rollback. Schlecht für die Performance wenn User auf die DB zugreifen.
2) Bei deinem Befehl schreibt er gleich ins Transaction Log bzw. muss beim Redo wieder davon lesen. Geht auf die Disk.

Beide Punkte treffen nicht zu wenn er die zu ändernden Datensätze mit einem SELECT abfragt.
 
@nittels: Aber anders geht's nicht "sauber":

Wenn er ein SELECT ausführt, und sofort danach jemand die Datensätze ändert, dann stimmt das Ergebnis vom SELECT nicht mehr mit der später auszuführenden Operation überein.

Einen Tod muss man sterben. Ich bin grundsätzlich aber auch pro Eventual Consistency. D.h. erst SELECT, dann UPDATE, ohne Transaction. Liefert halt nicht unbedingt das gewünschte "genaue" Ergebnis. Fragt sich halt, ob das überhaupt relevant ist. In 99% der Fälle, ist es vollkommen egal, ob da steht "es werden 4232 Datensätze geändert" und im Endeffekt ist es dann einer mehr oder weniger.
 
Technisch hast du absolut recht.

Ein Mittelweg wäre das Ändern des Isolation Levels auf Repeatable Read (geht z.B. beim SQL Server, kA wie das bei anderen Produkten ist). Dann packst du das Select mit in die Transaction und die Datensätze behalten ihren Shared Lock bis zum Commit/Rollback wodurch sie nicht geändert werden können (aber trotzdem gelesen). Wenn du dich dann für ein Update entscheidest änderst du genau diese Datensätze in derselben Transaction. Einziges Problem sind dann halt Ghost Records, also Datensätze die zwischen Select und Update mit einem Insert dazu gekommen sind. Aber du ersparst das schreiben bzw. lesen vom Translog wenn du dich gegen ein Update entscheidest.

Das wäre dann einer von drei Tode für die du dich entscheiden musst haha.

Praktisch brauchst du sowas aber eh nur zum Checken der Plausibilität, da sind dann ein paar Datensätze Abweichung zwischen Select/Update wie du richtig sagst egal.
 
Zurück
Oben