Om du har 10g Enterprise Edition bör du titta på Oracle's Fine-Grained Auditing. Det är definitivt bättre än att rulla ditt eget.
Men om du har en mindre version eller av någon anledning FGA inte är i din smak, så här gör du. Det viktigaste är:bygg en separat granskningstabell för varje programtabell .
Jag vet att det här inte är vad du vill höra eftersom det inte matchar tabellstrukturen du beskrev ovan. Men att lagra en rad med GAMLA och NYA värden för varje kolumn som påverkas av en uppdatering är en riktigt dålig idé:
- Den skalas inte (en enda uppdatering som rör tio kolumner skapar tio inlägg)
- Vad händer när du infogar en post?
- Det är svårt att sammanställa statusen för en post vid en given tidpunkt
Så ha en granskningstabell för varje applikationstabell, med en identisk struktur. Det betyder att inkludera CHANGED_TIMESTAMP och CHANGED_USER i applikationstabellen, men det är inte dåligt.
Slutligen, och du vet vart detta leder, ha en trigger på varje tabell som infogar en hel post med bara :NEW-värdena i granskningstabellen. Utlösaren bör aktiveras vid INSERT och UPPDATERA. Detta ger den fullständiga historiken, det är lätt nog att skilja två versioner av posten. För en DELETE kommer du att infoga en revisionspost med bara primärnyckeln ifylld och alla andra kolumner tomma.
Din invändning kommer att vara att du har för många tabeller och för många kolumner för att implementera alla dessa objekt. Men det är enkelt nog att generera tabellen och trigga DDL-satser från dataordboken (user_tables, user_tab_columns).