UPDATE nicht ausführen, wenn nichts?

[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.

[p80286]

Jetzt stell Dir vor, die Durchführung des Updates ist von einem Feld abhängig, das nicht "upgedated" wird, da kommst Du mit einem "wenn alles gleich ist" nicht so weit. Übrigens unterdrückt DISTINCT nur die Ausgabe gleicher Zeilen, das ist nur Kosmetik. Wenn es doppelte Datensätze geben sollte, sollte man auch wissen warum.

Gruß
K-H

[Sir Rufo]

Hmmm, UPDATE hat so etwas schon eingebaut.

Für den Trigger verwendet man ein TIMESTAMP Feld und in der Anwendung fragt man nach der Ausführung RecordsAffected ab (was dann 0 ist, wenn die Werte gleich waren).

Man kann sich das auch selber zusammenbauen wenn einem das nicht reicht

[himitsu]

Zitat:

RecordsAffected

Das UPDATE steht in einem Trigger einer anderen Tabelle, da gibt es das TDataSet nicht.
Es gibt zwar das FOUND (Update hat mindestens einen Datensatz getroffen ... abhängig vom WHERE), aber das ist ja keine Lösung, da es ja nicht meinen Trigger und den nachfolgenden Code, sondern andere Trigger betrifft (und die sind oft paar Jahrzehnte alt und demnach nicht immer gut gebaut).

Da man auch nicht "weiß" was für Trigger überall dran hängen oder mal dran hängen werden, ist auch ein DISABLE TRIGGER eine Lösung.



SELECT DISTINCT braucht ja auch keiner, da man das über ein passendes GROUP BY oder WHERE auch selber bauen könnte.

SQL-Code:

UPDATE CHANGED test
SET aaa = hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel,
    bbb = hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
WHERE id = ...
  AND nochwas

sähe doch besser aus, als

SQL-Code:

UPDATE test
SET aaa = hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel,
    bbb = hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
WHERE id = ...
  AND nochwas
  AND (aaa = hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
      hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel_hierganzviel
    OR bbb = hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel
      hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel_hierauchganzviel)

wenn das DBMS aaa mit dem Ergebnis von hierganzviel vergleichen und nur bei Unterschied das Update machen würde.

Ja OK, man könnte auch ein gang blöd eine Prüfung ala

SQL-Code:

IF old = new THEN  
  RETURN new
END IF;

in alle Trigger rein machen, aber wozu überhaupt den Datensatz updaten, wenn sich doch nix ändert.
PS: Wir haben an fast allen Tabellen einen echt doofen automatisch generierten Trigger, der nichts prüft und bei jedem UPDATE ein Feld modified_date=current_time setzt.
und dann teilweise noch paar Trigger, die manchmal nicht grade wenig machen. (z.B. die Mengen/Preise von allem neu berechnen)

Das GANZ_VIELE könnte ich zwar in einen LATERAL JOIN auslagern und dann im WHERE und SET quasi kurze temporäre Variablenbenutzen, aber da muß ich auch erstma gucken, wie das nochmal ging.

Bin doch bestimmt nicht der Einzige, der das bissl "doof" findet, da hätte man da doch auch gleich was in der SQL-Syntax für vorsehen können?

[Sir Rufo]

Darum sagte ich ja auch in der Anwendung kann man RecordsAffected abfragen - im Trigger verwendet man den TimeStamp

[Sir Rufo]

Wenn das mit dem TimeStamp/RecordsAffected nicht ausreicht wird man auf so ein Konstrukt zurückgreifen müssen.

Da dieses Konstrukt aber gewissen Regeln folgt, kann man sich auch ein kleines Programm schreiben, was einem die Erstellung dieser Statements erleichtert

[jobo]

Zitat von himitsu:

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.

Der Teil in meinem Vorschlag, der mit dem "Except" arbeitet, dient genau dazu, den Vergleich "Bestandsdaten zu Änderungen" zu übernehmen und bei Gleichheit eine leere Menge auszuspucken, sodass Update ins Leere läuft (siehe Thema des Threads), also 0 Rows affected.
Mit And/Or Muss man da innerhalb der Felder nichts machen, AND/OR benötigt man nur, um die Basisbedingung* des Update mit dem Except Teil zu verbinden.
Die Syntax bei PG erlaubt nun das Update genauso aufzubauen, wie eine Select Clause, einfach eine Feld- bzw Werteliste eintragen.
Damit ist "notfalls" dann das Generieren, eines solchen Statements sehr simpel.

@SirRufo: Was meinst Du in #13 mit "soetwas". Ich kenne nur updates, deren Updatecount (Rows Affected) über die Where Bedinung definiert sind.

@p80286: Die Anhängigkeit des Updates von anderen Feldern war nicht gefragt, sondern "hat sich überhaupt was geändert" oder? Aber so oder so, wenn das Update allein den Umfang der Updates bestimmt (ohne Trigger), hat man die größte Flexibilität.

*Die Basisbedinung kann natürlich auch n Haufen And/Or enthalten, aber das war nicht gemeint oder?

[Sir Rufo]

@jobo
Das meine ich damit

Delphi-Quellcode:

Query.SQL.Text := 'INSERT INTO foo ( id, bar ) VALUES ( 1, "foo" )';
Query.ExecSQL(); // Betroffene Zeilen 1

Query.SQL.Text := 'UPDATE foo SET bar = "foobar" WHERE id = 1';
Query.ExecSQL(); // Betroffene Zeilen 1

Query.SQL.Text := 'UPDATE foo SET bar = "foobar" WHERE id = 1';
Query.ExecSQL(); // Betroffene Zeilen 0 !!!!!

[jobo]

Zitat von Sir Rufo:

Das meine ich damit

Delphi-Quellcode:

..snipp
Query.SQL.Text := 'UPDATE foo SET bar = "foobar" WHERE id = 1';
Query.ExecSQL(); // Betroffene Zeilen 0 !!!!!

In meiner Welt kommt auch hier "Betroffene Zeilen 1" raus. Mir ist nicht bewusst, dass irgendwelche DB sich so verhalten.

[Sir Rufo]

Zitat von jobo:

In meiner Welt kommt auch hier "Betroffene Zeilen 1" raus. Mir ist nicht bewusst, dass irgendwelche DB sich so verhalten.

Wenn du MySQL als DB betrachtest, dann hast du damit schon eine