update trigger - datensatz nur bei änderung speichern

[rore]

Hallo,

Meine Frage ist vielleicht für die Profis blöd aber als SQL-firebird-newbie hoffe ich ihr könnt mir helfen.

Mein Problem:
In einer Datenbank speichere ich auch immer einen "changecounter" wenn ein Datensatz "geupdatet" wird über einen before update Trigger
changecounter sollen aber nur! aktualisiert werden, wenn sich tatsächlich die anderen Daten geändert haben - also nicht wenn die Daten unverändert noch mal geschrieben werden.

Einen Vergleich

if (new is distinct from old) then anderung=1;

gibt es soweit ich das verstanden habe nicht, sondern ich muss jedes Feld einzeln vergleichen

also bei eine Datenbank mit 40 Felder

anderung=0;
if (new.feld1 is distinct from old.feld1 then anderung=1;
if (new.feld2 is distinct from old.feld2 then anderung=1;
....
if (new.feld40 is distinct from old.feld40 then anderung=1;
if (anderung=1) then NEW.changecounter = OLD.changecounter +1;

gibt es da keine "einfachere Lösung" ?

[defo]

ohne spezielle Kenntnisse von Firebird Besonderheiten, frag ich einfach mal, wie soll es sonst gehen?
Fuzzy Logic?
Falls es Dir um "eleganteren Code" geht oder bequemeres Coding. Es gibt Systeme, die es erlauben, solche Art Abgleiche mit generischen Verfahren unter Zuhilfenahme des Dictionary und dynamischem SQL zu bearbeiten. Dann hättest eine OneCatchAll Lösung, die für alle Tabellen per Trigger aufgerufen werden kann. Ob das mit FB möglich ist, weiß ich nicht.
Es gibt außerdem Clientseitige Komponenten, die Alt/Neu Wert mitverwalten und es so erlauben, gezieltere Updates zu konstruieren. Also ein Update, das per se nur Felder beinhaltet, deren Wert sich wirklich geändert hat. Der Counter läge also bedingungslos immer richtig im Update Statement. Da wäre die Frage, ob die Clientlandschaft homogen genug ist, dass ausschließlich solche Verfahren zum Einsatz kommen. Und ob man sich den Resourcenaufwand innerhalb eines Update Triggers erlauben kann/will.
Gerade fällt mir ein, dass Firebird eine spezielle Technik verwendet, um Updates zu speichern, der Datensatz wird quasi historisiert, ein vollkommen neuer DS an anderer Stelle geschrieben, der alte dann gemäß Transaktionshandling ausgeblendet oder wieder verwendet (Commit/Rollback). Vielleicht kann man sich das irgendwie zunutze machen, aber meine Kenntnisse sind da sehr oberflächlich und ich fürchte, das ist kein Mechanismus, der als offizielle Schnittstelle verfügbar ist.