Warum hat das UPDATE-SQL kein Flag für "tu nichts, wenn sich kein Feld ändert" ?

Wenn ich nicht will, dass Trigger ausgelöst werden, wenn sich nicht ändert, dann darf ich alle Felder im SET nochmal im WHERE gegenprüfen.
> Doppelter Code
> OK, wenn es richtig viel wird, könnte man die Auswertungen z.B. in einen LATERAL-JOIN auslagern und im WHERE/SET nur noch das Ergebnis vergleichen/zuweisen.

markieren

SQL-Code:

UPDATE test
SET aaa = hierganzviel
    bbb = hierauchganzviel
WHERE id = ...
  AND aaa IS DISTINCT FROM hiernochmalganzviel
  AND bbb IS DISTINCT FROM hierauchnochmalganzviel

Aber so ein "kurzer" Befehl ala "DISTINCT" wäre doch eigentlich ganz praktisch?

Zitat von himitsu:

Warum hat das UPDATE-SQL kein Flag für "tu nichts, wenn sich kein Feld ändert" ?

Weil der mündige Benutzer nie im Leben bereits vorhandene Daten mit sich selbst überschreiben würde?
Und wenn doch, dann hat er gute Gründe dafür?


Gruß
K-H

Außerdem ist der DB-Aufwand, das zu prüfen auch einfach höher als einfach ohne Prüfung zu schreiben. Man müsste ja bei jedem Schreibvorgang vorher erst noch prüfen, ob die Daten übereinstimmen.

Darum ja auch als "aktivierbares" Zusatzfeature, das Standardmäßig nicht aktiv ist.
Um nur die Trigger neu anzustoßen, machen Viele oft einfach einen Post ohne Änderung, ala SET aaa=aaa Der Aufwand das selber zu prüfen ist auch größer (längeres SQL und eventuell doppelte Auswertung), als wenn die DB das von selber schon könnte.


Ich finde das wäre ein gutes Grundfeature, so wie ein INSERT OR UPDATE.

Oder im Trigger prüfen was und ob sich etwas geändert hat und nur dann eine Aktion ausführen

Zitat von Fritzew:

Oder im Trigger prüfen was und ob sich etwas geändert hat und nur dann eine Aktion ausführen

genau, das ist das Standardprocedere!

Nur mal so dahingedacht:

• Der UPDATE -Trigger wird immer ausgelöst, wenn ein UPDATE Statement abgesetzt wird.
• Ein TIMESTAMP Feld (mit ON UPDATE CURRENT_TIMESTAMP ) wird nur dann aktualisiert, wenn sich wirklich Daten in der Zeile ändern.

Im UPDATE -Trigger braucht man jetzt also nur noch zu prüfen, ob es eine Änderung im TIMESTAMP Feld gibt (IF OLD.ts <> NEW.ts THEN ) und schon kann man darauf gesondert reagieren.

So funktioniert es z.B. bei MySQL

Per Trigger mit :new/ :old zu arbeiten ist wahrscheinlich das gängige Verfahren.
Alternativ kannst Du das Update so gestalten, dass es
- 0 Rows betrifft und damit auch
- ein Trigger nicht zündet bzw.
- ein Trigger gar nicht definiert sein muss oder
- unspezifisch sein kann:
Für ein "leeres" Update kann man z.B. als Bedingung

markieren

Code:

where exists

mit

markieren

Code:

Select <aktueller Feldinhalt/Felder> from UpdateTable where..
except
Select <neue Feldwerte oder bestehende Feldwerte> from <jenachdem> <where ..>

kombinieren.

Das ist wahrscheinlich nicht viel weniger als "ganz viel und hier auch ganz viel", aber es hat den Charme, dass man nicht nachdenken muss und die Statements anhand der Felder der Tabelle generisch bauen kann (ohne PK und andere frei wählbare Ausnahmen). Ob es dann zündet, regelt das "except".
Was final geupdated wird, steht unabhängig davon in der Update ExpressionList. Kann man gut finden, weil weiterer Freiheitsgrad, kann aber auch falsch gemacht werden.

Andere DB können im Update statt der ExpressionList auch gleich Selects verwenden, dass macht es etwas eleganter.

Unterscheiden muss man hier bei den Where Bedingungen natürlich zwischen SingleRow Updates und Massenupdates.

Aber warum so umständlich, wenn man das mit einem TIMESTAMP Feld komplett erschlagen kann?

Es ist einfach eine Möglichkeit, damit und mit anderen Problemen umzugehen. Sozusagen eine Ikea Antwort, entdecke die Möglichkeiten.

Ich brauche/will/darf keinen Trigger,
Ich brauche/will/darf kein Update Feld,
Ich habe in PG nicht direkt die MySQL On Update Definition zur Verfügung,

Es ist flexibler als ein Catchall Update Timestamp:
Wenn bspw. beim Kunden ein Tippfehler in der Anschrift korrigiert wird, interessiert mich vielleicht dieses Update Event, wechselt aber ein Flag / Statusfeld durch eine BusinessOperation seinen Wert, interessiert mich das vielleicht überhaupt nicht als Kundenupdate Event, weil die BO den Event implizit logged/dokumentiert.

Und kompliziert ist ja relativ, innerhalb eines Update Statementgerüsts ist es nichts viel mehr als die Wiederholung einer Feldliste/Parameterliste.
Update myTable
set
<feldliste>
<parameterliste>
where
<corecondition>
and exists
(
select <feldliste> from myTable where <corecondition>
except
select <parameterlist> [from myTable where <corecondition]>
)