Hvis du har 10g enterprise-udgave, bør du se på Oracle's Fine-Grained Auditing. Det er bestemt bedre end at rulle din egen.
Men hvis du har en mindre version, eller af en eller anden grund FGA ikke falder i din smag, er det her, hvordan du gør det. Det vigtigste er:byg en separat revisionstabel for hver applikationstabel .
Jeg ved, at det ikke er det, du ønsker at høre, fordi det ikke matcher den tabelstruktur, du skitserede ovenfor. Men at gemme en række med GAMLE og NYE værdier for hver kolonne, der påvirkes af en opdatering, er en rigtig dårlig idé:
- Den skaleres ikke (en enkelt opdatering, der berører ti kolonner, afføder ti indsættelser)
- Hvad med, når du indsætter en post?
- Det er en komplet smerte at samle en posts tilstand på ethvert givet tidspunkt
Så hav en revisionstabel for hver applikationstabel med en identisk struktur. Det betyder at inkludere CHANGED_TIMESTAMP og CHANGED_USER på applikationstabellen, men det er ikke en dårlig ting.
Endelig, og du ved, hvor dette fører hen, har du en trigger på hver tabel, som indsætter en hel post med kun :NEW værdierne i revisionstabellen. Udløseren skulle udløses ved INSERT og OPDATERING. Dette giver den komplette historie, det er nemt nok at skelne mellem to versioner af posten. For en DELETE vil du indsætte en revisionspost med kun den primære nøgle udfyldt og alle andre kolonner tomme.
Din indvending vil være, at du har for mange tabeller og for mange kolonner til at implementere alle disse objekter. Men det er simpelt nok at generere tabellen og udløse DDL-sætninger fra dataordbogen (brugertabeller, brugertabskolonner).