Si tiene la edición empresarial 10g, debe consultar la auditoría detallada de Oracle. Definitivamente es mejor que enrollar el tuyo propio.
Pero si tiene una versión menor o por alguna razón FGA no es de su agrado, aquí le mostramos cómo hacerlo. La clave es:crear una tabla de auditoría separada para cada tabla de aplicación .
Sé que esto no es lo que quiere escuchar porque no coincide con la estructura de la tabla que describió anteriormente. Pero almacenar una fila con valores ANTIGUOS y NUEVOS para cada columna afectada por una actualización es una muy mala idea:
- No escala (una sola actualización que toca diez columnas genera diez inserciones)
- ¿Qué pasa cuando insertas un registro?
- Es una completa molestia ensamblar el estado de un registro en un momento dado
Por lo tanto, tenga una tabla de auditoría para cada tabla de aplicación, con una estructura idéntica. Eso significa incluir CHANGED_TIMESTAMP y CHANGED_USER en la tabla de aplicaciones, pero eso no es malo.
Finalmente, y ya sabe adónde lleva esto, tenga un activador en cada tabla que inserte un registro completo con solo los valores :NUEVO en la tabla de auditoría. El activador debe activarse en INSERTAR y ACTUALIZAR. Esto da la historia completa, es bastante fácil diferenciar dos versiones del registro. Para una ELIMINACIÓN, insertará un registro de auditoría con solo la clave principal completa y todas las demás columnas vacías.
Su objeción será que tiene demasiadas tablas y demasiadas columnas para implementar todos estos objetos. Pero es lo suficientemente simple como para generar la tabla y activar declaraciones DDL desde el diccionario de datos (user_tables, user_tab_columns).
