No estoy seguro de que haya un "mejor enfoque", hay tantas variables a tener en cuenta, incluido qué tan avanzado está en el camino del desarrollo.
Después de haber pasado por soluciones de auditoría tanto basadas en código como basadas en db-trigger, he enumerado algunos comentarios a continuación; Espero que pueda ver dónde se encuentra ahora (en términos de desarrollo) podría afectar estos problemas:
- Si necesita mapear al usuario que cambió los datos (lo que normalmente hace), entonces los disparadores de db necesitarán obtener esta información de alguna manera. No es imposible, pero requiere más trabajo y varias formas de abordar esto (usuario de base de datos ejecutando consulta, columna de usuario común en cada tabla, etc.)
- Si utiliza disparadores de base de datos y confía en el recuento de filas afectadas que devuelven las consultas, entonces sus disparadores de auditoría deben tener esto desactivado, o su código existente debe modificarse para tenerlos en cuenta.
- En mi humilde opinión, los activadores de base de datos ofrecen más seguridad y ofrecen un camino más fácil para la automatización de auditorías; sin embargo, no son infalibles, ya que cualquier persona con acceso adecuado puede desactivar los activadores, modificar los datos y volver a activarlos. En otras palabras, asegúrese de que sus derechos de acceso de seguridad a 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 por hacer (y datos para 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 que intentan escribir en una tabla de auditoría.
- Tener una tabla de historial de auditoría para cada tabla es otra opción. Solo necesita que cada columna de la tabla de auditoría sea anulable, además de almacenar la fecha y la hora de la acción (insertar/actualizar/eliminar) y el usuario asociado con la acción.
- Si opta por la opción de una sola tabla, a menos que tenga mucho tiempo para dedicarlo a esto, no sea demasiado sofisticado tratando de auditar solo las actualizaciones o eliminaciones, aunque puede ser tentador evitar las inserciones (ya que la mayoría las aplicaciones hacen esto con más frecuencia que 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, almacenar la fecha del evento de auditoría en UTC e 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, piense en esto ahora y no cuando se convierta en un problema :)
