estructura de tabla de auditoría

Question

Estoy construyendo tablas de auditoría para mi base de datos y necesito elegir qué estilo implementar. Actualmente estoy considerando tres opciones, todas las cuales se completarán con los activadores:

1. Una sola tabla con los campos id | mesa | columna | fila | old_value | new_value | marca de tiempo | identidad de usuario. Esto haría un seguimiento de todos los cambios en todas las tablas en un solo lugar y tiene el beneficio de minimizar el número de tablas. Hace las consultas un poco difíciles, pero no imposibles.
2. Múltiples tablas como # 1, excepto sin la columna de la tabla. Esto separaría los cambios de cada tabla en su propia tabla de historial.
3. Múltiples tablas que reflejan el esquema de las tablas originales para rastrear. Esto facilitaría la escritura de los factores desencadenantes, facilitaría la restauración de los datos si alguien quisiera volver a un registro específico, pero vendría a expensas del almacenamiento, ya que cada campo, incluso si no hubiera cambiado, lo haría ser duplicado, posiblemente varias veces. Además, sería difícil saber específicamente qué campos cambiaron de una versión a la siguiente.

Cada una de estas tres opciones es factible, y por lo que yo sé, no hay una funcionalidad que se ofrece que es imposible en otra. Entonces debe haber algo que no estoy considerando o algún patrón que sea más estándar. Si hace alguna diferencia, esta solución debe funcionar para ambos servidores, mysql y sql (aunque puedo resolver los detalles del código más adelante).

Answer 1

Las tablas de auditoría se ven afectadas muy fuertemente, no desea solo una tabla para todas las auditorías u obtendrá bloqueos.

Hacemos algo así como el número dos, excepto que tenemos dos tablas por tabla (una que almacena las instancias de cambios y otra que almacena los datos reales. Esto hace que sea fácil encontrar todos los registros almacenados en una importación de registros amillion por ejemplo, ya que todos son en la misma instancia. Esto significa que podemos crear fácilmente nuevas tablas de auditoría a medida que se agregan nuevas tablas.

En el caso de la segunda, sugeriría escribir un procedimiento para restaurar un registro específico la restauración es fácil y no tiene que resolverlo cada vez.

Answer 2

Elegiría el número 1 con la mano hacia abajo. El número 2 sería difícil de mantener si decide agregar campos adicionales a su seguimiento y agrega muy poco además de eliminar la necesidad de una tabla WHERE =? cláusula. El número 3 es exagerado. Para eso están las copias de seguridad.

Answer 3

No hay respuesta, solo otras preguntas: ¿Para qué sirve su tabla de auditoría? m, o tiene que tenerlos? ¿Cómo se usarán, qué preguntas responderán o qué situaciones abordarán? ¿Con qué frecuencia o con poca frecuencia se usarán? ¿Cuánto tiempo debe mantener estos datos disponibles, y cómo va a purgarlos o archivarlos después de la fecha de vencimiento?

Las dos respuestas anteriores [theChrisKen, HLGEM] no coinciden, sin embargo, según lo que han trabajado antes, apostaría a que ambas son correctas. Si considera cómo serán utilizados y los requisitos de rendimiento de ese uso, eso puede ayudarlo a determinar qué modelo es mejor para su situación.