Oracle logging Trigger

[kelmar]

Hallo Leute,

Ich versuche in PL SQL einen Trigger zu schreiben, der bei jedem Update alle geänderten Felder in einer Logging-Tabelle speichert.
Das ganze sollte so sein, dass man nicht immer explizit jedes Feld angeben muss.
Dies wäre beim hinzufügen eines Feldes problematisch, da man an die ganzen Trigger denken muss....

So weit bin ich gekommen....

create or replace trigger "BENUTZER_T1"
AFTER
update on "BENUTZER"
for each row
begin
for row in (select COLUMN_NAME from USER_TAB_COLUMNS WHERE TABLE_NAME = 'BENUTZER')
loop
  if updating (row.COLUMN_NAME) then
    INSERT INTO logs (aktion, tabelle, feld, datum) VALUES ('UPDATE', 'BENUTZER', row.COLUMN_NAME, SYSDATE);
  end if;
end loop;
end;

Mein Problem ist im Moment das row.COLUMN_NAME in dieser Variable steht das zu überprüfende Feld. Anscheinend wird das aber nicht richtig erkannt, da PL SQL keine Variablenersetzung vornimmt...
Auch müsste ich über ld und :new.row.COLUMN_NAME auf die alten und neuen Werte zugreifen können.

Kann mir jemand von euch nen kleinen Tipp geben?

Gruß und Danke!
Markus

[dimitri]

Das ganze sollte so sein, dass man nicht immer explizit jedes Feld angeben muss.

Deshalb generiert man solche Trigger auch während der Entwicklung und tauscht sie mit einer neuen Version aus. Gleiches gilt auch für die Loggingtabellen selbst.

Bei jedem Update die Systemviews zu durchsuchen wird dir ernsthafte Performanceprobleme bereiten wenn die Systemlast mal höher wird.

Dim

[kelmar]

Schon mal vielen Dank!

Hast du ne Idee wie ich das jetzt zum Testen so hinbekomme?

Da sich die Software und die Datenbank öfters ändern wird, wollte ich das halt möglichst dynamisch gestallten.

Gibt es dafür keine andere Lösung als alles jedes Feld von Hand aufzuführen?

[dimitri]

Wie gesagt: Du schreibst Dir ein kleines PL/SQL/Java/C/... Programm, welches die Trigger anhand der Metainformationen generiert.

Wir machen das mit Templates und einem Java Programm. Das Template beschreibt den Trigger incl. diverser Variablen, die dann im Programm entsprechend ausgetauscht werden. Die Informationen wie die Variablen ausgetauscht werden holen wir uns aus der DB selbst.
Das ganze ist in den Buildprozess eingebunden, so dass am Ende des Builds zum einen die fertigen Schemata in einer sog. BUILD Instance aufgebaut sind und auch die dazu benötigten (fest + generiert) Skripte bereit liegen.

So etwas in der Art musst Du auch aufbauen, damit Du eine einheitliche Version erstellen kannst, in der die DB zum Programm passt.

Das ganze natürlich über ein Versionierungssystem entsprechend verwaltet.

Dim

[kelmar]

Alles klar! Danke!

Dann werde ich mir das mal anschauen....