Ver Mensaje Individual
  #6  
Antiguo 21-11-2008
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 25
Delphius Va camino a la fama
Bueno, si vas o no borrando los registros más antiguos eso ya es otra cosa. En fin, todo dependerá de las necesidades y de como se planea el sistema y la base de datos.

Con respecto a 6 trigger por tabla, me parece que es demasiado claro. Los triggers pueden ser AFTER y/o DEFORE y se pueden aplicar en INSERT, UPDATE, y DELETE. Esto lleva a que exista 6 combinaciones posibles.

No importa si se usan las 6, 5, o 1... la cuestión es que si N es la cantidad de tablas a auditar, y M son la cantidad (en promedio) de acciones a vigilar entonces tendrás NM triggers. ¡Sigue la misma proporción que he dado a conocer antes! No importa cuantas tablas sean... la cantidad total de triggers, será linealmente proporcional.

Y si dejamos en claro que cuanto más grande sea N y cuantas más relaciones maestro-detalle existan, mayor será el impacto en la bitácora, provocando en ciertas ocasiones efectos de cascada. Es decir que cabe la posibilidad de que una simple acción por parte de un usuario se consigan cantidades en una progresión lineal. Veamos un ejemplo, Supongamos que el usuario ha realizado en X facturas, cada factura tiene en promedio Y registros detalles que han sido alterados (es un ejemplo... si). Si existe un plan de bitácora para estas dos tablas, tendremos que se han insertado XY registros. Ahora supongamos que ante alguna acción sobre estos registros detalles se deben realizar algunos cambios en otro conjunto de datos, supongamos que sea Z datos por cada campo detalle, si existe otro plan de auditoria sobre la tabla que guarda estos Z datos... entonces ahora existirán tal vez, en un escenario de un peor caso, un valor de XYZ.

Se ve ahora, los peligros de hasta donde se puede llegar. Por ello me tomo el tiempo para escribirte este rollo. Debes definir adecudamente el alcance de la bitácora.
Además, no es una cuestión de que y cuantas tablas, sino de los campos que la constituyen... las "estadísticas" que te mostré pueden ser mejoradas si lo analizamos en éste contexto: ¿qué campos se necesitan auditar? ¿Todos? ¿algunos? Imaginate de que una tabla tenga 40 campos, y un usuario cambia 20... ¿cuantos registros se agregan a la bitácora? ¿1 que asocie a todos, o 20 campos: uno por cada campo que ha sido alterado?

Bueno mejor no suelto más rollo, creo que con esto se entiende la idea.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]

Última edición por Delphius fecha: 21-11-2008 a las 02:52:57. Razón: anteriormente dije progresión geométrica, en realidad es lineal
Responder Con Cita