auditoria de tablas

[Rodrigo Fuentealba]

2006/11/14, javier calderon <kivurkian en gmail.com>:
> Amigos podian aclararme la razon de ocupar tablas repetidas de aquellas que
> desean auditar y no una sola tabla bitacora y valerse de las tablas
> virtuales del motor de base datos (en sqlserver INSERTED / DELETED)
> ejecutando el llenado a la tabla bitacora mediante triggeres o
> procedimientos almacenados  los datos que se requieran ....

Comparemos:

1.- tablas repetidas:

PRO 1.- más fáciles de leer. (basta un select a audit_tabla)
PRO 2.- más compatibles al migrar entre una BD y otra.
PRO 3.- más mantenibles, ya que puedes poner lo que se te ocurra de
info sobre el cambio que estás haciendo.
PRO 4.- puedes respaldar la información de auditoría cuando se te plazca.

CONTRA 1.- más espacio en disco.

2.- tabla bitácora:

PRO 1.- más compatibles al migrar entre una BD y otra.

CONTRA 1.- más difícil de leer (y si yo quiero filtrar por otro tipo
de cambios?)
CONTRA 2.- menos mantenibles, tienes que adaptar la estructura a algo
que te sirva para todas las tablas que quieras mantener.
CONTRA 3.- no puedes poner lo que se te ocurra de info.
CONTRA 4.- al final ocupas lo mismo de espacio en disco y en vez de
tener 100 tablas con 100 registros, tienes una sola tabla con 10000
registros: más lenta la base de datos para auditar.

3.- tablas virtuales de sql server:

PRO 1.- SQL Server modifica tu tabla original y le agrega esos campos
sin que tú los veas para que todas las operaciones las hagas sobre una
vista SELECT de tu base creada, y los datos de auditoría los sacas de
una vista INSERTED/DELETED de tu base. (En resumen, lo que había
planteado yo). Eso tiene como pro el hecho de que no tienes que
duplicar tablas.

CONTRA 1.- están solo en SQL Server: no son compatibles.
CONTRA 2.- no es mantenible sino por SQL Server.
CONTRA 3.- no puedes poner lo que se te ocurra de info (aunque la que
te entrega es bastante útil)
CONTRA 4.- no puedes guardar la información completa de auditoría si
quieres respaldar la tabla.

4.- XML log

CONTRA 1.- anda a que te borren el log en XML...
CONTRA 2.- anda a que hagan una inserción por otro lado usando otro sistema...
CONTRA 3.- anda a mantenerlo sincronizado...
CONTRA 4.- anda a reconstruir la información a partir de un momento
dado "sin" cabronearte porque tienes que construir un archivo que te
parsee el XML.

PROs? Si tu novia no sabe lo que es XML, ninguno...!!! Si lo sabe,
tienes un 50% de probabilidades de que te ame por ser XML Wizard, y el
otro 50% es que se ría de ti por haber elegido algo tan frágil para
guardar información ;-)

XML es super útil para "transporte" de información, pero para guardar
información como la necesaria en este caso, se torna bastante
inmanejable, y yo recomiendo alejarse de estas situaciones... aparte
Dios mata a una palomita blanca cada vez que abusas del XML en tareas
para las que claramente /no/ está hecho... (De hecho, para que se den
cuenta de que tengo razón, la gripe aviar salió a la luz pública más o
menos en la misma fecha que el estándar SQL 4, que trae extensiones
para guardar formatos XML)

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org