UPDATE nicht ausführen, wenn nichts?

[Fritzew]

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

[TBx]

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!

[Sir Rufo]

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

[jobo]

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

Code:

where exists

mit

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.

[Sir Rufo]

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

[jobo]

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]>
)

[himitsu]

Zitat von jobo:

Und kompliziert ist ja relativ, innerhalb eines Update Statementgerüsts ist es nichts viel mehr als die Wiederholung einer Feldliste/Parameterliste.

Jupp, dieses Doppelte hätte man sich ja sparen können, wenn das UPDATE-Statement dafür eine integrierte Funktion hätte.

So ala dem SELECT DISTINCT ... (EIN Befehl zum Filtern von Wiederholungen) vielleicht ein UPDATE CHANGED table SET ... .


Im Prinzip kann ich ja "einfach" Den TEIL aus dem SET ins WHERE kopieren,
drumrum ein AND ( ...) , aus den Kommas je ein OR und fertig.

Vor eine Weile hatte ich ein Statement, da war das im SET nur knapp 20 Zeilen lang und bissl breit ... da sieht das "einfach" bissl blöd aus und bei Änderungen muß man dann auch beide Stellen anpassen, sonst knallt es ja.