auditoria de tablas

[javier calderon]

Bastante claro rodrigo... yo usaba  la opcion de tabla bitacora, bueno mi
necesidad  basicamente era registrar lo datos modificados en las tablas que
viendolo de un punto objetivo, no era una gran base de datos (10 tablas) +
la bitacora ...

comenzaré a utilzar esto de las tablas repetidas... muchas gracias

2006/11/14, Rodrigo Fuentealba <darkprox en gmail.com>:
>
> 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
>
>


-- 
Javier Calderón.
Ing. Ejec. Informatica
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.inf.utfsm.cl/pipermail/php/attachments/20061114/f0b35db5/attachment-0001.html