Als u een 10g enterprise-editie heeft, moet u eens kijken naar Oracle's Fine-Grained Auditing. Het is absoluut beter dan zelf rollen.
Maar als je een mindere versie hebt of om de een of andere reden FGA niet naar jouw smaak is, kun je dit als volgt doen. Het belangrijkste is:bouw een aparte controletabel voor elke toepassingstabel .
Ik weet dat dit niet is wat je wilt horen, omdat het niet overeenkomt met de tabelstructuur die je hierboven hebt geschetst. Maar het opslaan van een rij met OUDE en NIEUWE waarden voor elke kolom die wordt beïnvloed door een update is een heel slecht idee:
- Het schaalt niet (een enkele update die tien kolommen aanraakt, levert tien invoegingen op)
- Hoe zit het als je een record invoegt?
- Het is een hele klus om op elk moment de staat van een record te verzamelen
Zorg dus voor een audittabel voor elke toepassingstabel, met een identieke structuur. Dat betekent dat de CHANGED_TIMESTAMP en CHANGED_USER in de toepassingstabel worden opgenomen, maar dat is geen slechte zaak.
Ten slotte, en u weet waar dit toe leidt, heeft u een trigger op elke tabel die een heel record met alleen de :NEW-waarden in de controletabel invoegt. De trigger moet worden geactiveerd bij INSERT en UPDATE. Dit geeft de volledige geschiedenis, het is gemakkelijk genoeg om twee versies van het record te onderscheiden. Voor een VERWIJDERING voegt u een controlerecord in met alleen de primaire sleutel ingevuld en alle andere kolommen leeg.
Uw bezwaar zal zijn dat u te veel tabellen en te veel kolommen heeft om al deze objecten te implementeren. Maar het is eenvoudig genoeg om de tabel te genereren en DDL-instructies te activeren vanuit de datadictionary (user_tables, user_tab_columns).