¿Es este el mejor enfoque para crear una pista de auditoría?

Question

Estoy intentando crear alguna funcionalidad que mantenga un seguimiento de auditoría de cómo los datos en un formulario de usuario determinado han cambiado a lo largo del tiempo, con una auditoría fechada al pie de esa página.Por ejemplo:

04/02/09 21:49 El nombre cambió de "Tom" a "Chris".

Hago esto almacenando los datos en su formato actual en la sesión y luego, al guardarlos, comprobo si hay alguna diferencia en los datos que se almacenan.Si los hay, almaceno los datos como estaban antes de la última edición en una tabla llamada historial y almaceno los nuevos valores en la tabla de usuario actual.

¿Es este el mejor enfoque a seguir?

Answer 1

Una sugerencia; esto sería relativamente fácil de hacer en un trigger. En ese caso, usted nunca tiene que preocuparse acerca de si el código que se ejecuta la actualización recuerda añadir un registro histórico.

Answer 2

No estoy seguro de que exista un "mejor enfoque", hay muchas variables a tener en cuenta, incluido qué tan avanzado se encuentra en el camino de desarrollo.

Después de haber pasado por soluciones de auditoría basadas en código y activadas por db, he enumerado algunos comentarios a continuación;Espero que puedas ver dónde te encuentras ahora (en términos de desarrollo) podría afectar estos problemas:

• Si necesita asignar al usuario que cambió los datos (lo que normalmente hace), los activadores de base de datos necesitarán obtener esta información de alguna manera.No es imposible, pero hay más trabajo y varias formas de abordar esto (usuario de la base de datos ejecutando la consulta, columna de usuario común en cada tabla, etc.)
• Si utiliza activadores de base de datos y confía en el recuento de filas afectadas devueltas por las consultas, entonces sus activadores de auditoría deben tener esto desactivado o modificar su código existente para tener en cuenta ellos.
• En mi humilde opinión, los activadores de base de datos ofrecen más seguridad y ofrecen un camino más fácil para auditar la automatización; sin embargo, no son infalibles, ya que cualquier persona con el acceso adecuado puede desactivar los activadores, modificar los datos y luego habilitarlos nuevamente.En otras palabras, asegúrese de que sus derechos de acceso a la seguridad de la base de datos sean estrictos.
• Tener una sola tabla para el historial no es una mala manera de hacerlo, aunque tendrá más trabajo que hacer (y datos que almacenar) si está auditando el historial de varias tablas, especialmente cuando se trata de reconstruir la pista de auditoría.También debe considerar los problemas de bloqueo si hay muchas tablas intentando escribir en una tabla de auditoría.
• Otra opción es tener una tabla de historial de auditoría para cada tabla.Solo necesita que cada columna de la tabla de auditoría sea anulable, además de almacenar la fecha y hora de la acción (insertar/actualizar/eliminar) y el usuario asociado con la acción.
• Si opta por la opción de tabla única, a menos que tenga mucho tiempo para dedicarle a esto, no se le ocurra intentar auditar solo las actualizaciones o eliminaciones, aunque puede resultar tentador evitar las inserciones (ya que la mayoría de las aplicaciones hacen esto). con más frecuencia que las actualizaciones o eliminaciones), reconstruir el historial de auditoría requiere bastante trabajo.
• Si sus servidores o datos abarcan varias zonas horarias, considere usar un tipo de fecha y hora apropiado para poder almacenar y reconstruir la línea de tiempo, es decir,almacene la fecha del evento de auditoría en UTC, además de incluir el desplazamiento de la zona horaria.
• Estas tablas de auditoría pueden volverse enormes, así que tenga una estrategia si comienzan a afectar el rendimiento.Las opciones incluyen partición de tablas en diferentes discos, archivado, etc.Básicamente piensa en esto ahora y no cuando se convierta en un problema :)

Answer 3

Siempre he sido un fan de la utilización de una tabla en lugar de dividirlo en una mesa "activa" y una mesa de "historia". Pongo 4 columnas en estas tablas, todas las marcas de tiempo: crear, eliminar, inicio, fin. "Creado" y "eliminado" se explica por sí misma. Las marcas de tiempo "Inicio" y "fin" son para cuando el registro fue en realidad el registro "activa". El registro que se activa tendría un tiempo de "empezar" antes de la now() y un tiempo NULL "fin". Por la separación de los tiempos "y" creados "Inicio", puede programar cambios tengan lugar en el futuro.

Este diseño, en comparación con el diseño de dos mesa, le permite escribir fácilmente consultas que funcionarán automáticamente en los datos correctos. Supongamos que su mesa está almacenando la tasa de impuestos a través del tiempo ... que no quieren tener todas sus consultas que utilizan las tasas de impuestos en sus cálculos tienen la complejidad adicional de la decisión de buscar cosas en una tabla de historial en el tratamiento de facturas viejas, por ejemplo ... se puede simplemente buscar la tasa vigente en el momento de la factura fue creado en una consulta, independientemente de si se trata de la tasa vigente o no.

Esta idea no es original mía (aunque me hizo volver a inventar la idea aproximada por mi cuenta antes de leer sobre él) ... se puede encontrar una descripción detallada de la misma en este línea libro .

Answer 4

La participación sesión me hace un poco de dudas (¿está seguro de que está manejando correctamente cuando dos usuarios están trabajando en los mismos datos al mismo tiempo?), Pero en general, sí, manteniendo una tabla de historia es la derecha cosa.

Answer 5

Me gustaría también pensar en un trigger de inserción o actualización para registrar los detalles de cambio (quién, cuándo, qué valor antes, después de valor) a una tabla de auditoría independiente. Así, usted sabe que incluso si los datos se cambia outide de su aplicación directamente a través de la base de datos, que será recogido todavía hacia arriba.

También puede ser que desee hacer algo para detectar si los datos se cambia outide de su aplicación, tales como calcular un hash o CRC del registro y almacenarlo en un campo en algún lugar, a continuación, comprobar que la lectura de los datos.

Answer 6

Creo que su propuesta implicaría escribir mucho código / metadatos para permitir la comparación de objetos / registros para que pueda obtener una auditoría a nivel de negocio.

Como alternativa, un trigger no le puede dar una visión lo suficientemente alto nivel de lo sucedido. Esto puede ser aceptable si se utiliza la auditoría con tan poca frecuencia que el esfuerzo de recrear el significado de negocios está bien.

Esto también parece una buena aplicación para AOP (Aspectos), donde se puede utilizar la reflexión sobre el modelo de objetos para volcar algo significativo sin necesidad de una gran cantidad de metadatos.