Implementando Audit Trail- Spring AOP vs.Hibernate Interceptor vs DB Trigger

Question

Encontré un par de hilos de discusión sobre esto, pero nada que trajo una comparación de los tres mecanismos en un hilo.

Así que aquí está mi pregunta ...

necesito para auditar cambios-DB inserción \ Updates \ elimina a los objetos de negocio.

me ocurren tres maneras de hacer esto desencadena

1) DB

2) Hibernate interceptores

3) Spring AOP

(Esta pregunta es específica de una primavera \ Hibernate \ RDBMS: supongo que es neutral para java \ C# o hibernate \ nhibernate, pero si su respuesta depende de C++ o Java o de la implementación específica de hibernate, especifique)

¿Cuáles son los pros y los contras de seleccionar una de estas estrategias?

No estoy pidiendo detalles de implementación. Esta es una discusión de diseño.

estoy esperando que podemos hacer esto como parte de la comunidad wiki

Answer 1

Solo puedo hablar de Triggers y NHibernate, porque no conozco suficiente sobre Spring AOP.

Depende de, como siempre, lo que es más importante para usted.

DB desencadena

• son rápidos
• siempre son llamados, incluso de SQL nativo, secuencias de comandos, aplicaciones externas.
• escribe datos en la base de datos que NH no conoce. Faltará en la sesión actual. (Que podría conducir a resultados inesperados)
• Por lo general, no se sabe nada acerca de su sesión (por ejemplo: nombre de usuario).

NHibernate interceptores/eventos

• no se DBMS específico.
• le permiten acceder fácilmente a su información comercial, como la sesión del usuario, nombre de la máquina del cliente, ciertos cálculos o interpretaciones, localización, etc.
• permiten la configuración declarativa, como atributos en la entidad, que definen si la entidad necesita para ser registrado y cómo.
• le permiten apagar el registro, esto podría ser importante para actualizaciones, importaciones, acciones especiales que no se desencadenan por el usuario.
• le permiten una vista de entidad para el modelo de negocio. Probablemente estés más cerca del punto de vista de los usuarios.

Answer 2

No puedo pensar en ninguna buena razón para no usar la base de datos disparadores para auditar los cambios en la base de datos. Las inserciones, actualizaciones y eliminaciones pueden golpear la base de datos desde varias fuentes: los desencadenantes detectarán todas estas; Hibernate etc. no lo hará.

Answer 3

Creo que al considerar la auditoría, debe considerar para qué sirve. En primer lugar, es para tener un registro de quién cambió qué y qué cambió para poder evitar los cambios incorrectos, puede identificar problemas con el sistema (podemos ver cuál de las diferentes aplicaciones modificó el cambio, lo que ayuda a identificar rápidamente cuál está roto). y entonces puedes identificar quién hizo el cambio. Lo último puede ser realmente crítico cuando se trata de detectar fraudes. Si hace todo desde la interfaz de usuario, nunca verá al usuario que comete un fraude que cambia los datos en el backend para autoevaluarse. Si haces todo desde la interfaz, es probable que tengas que tener los permisos establecidos en el nivel de tabel, lo que te abrirá la puerta al fraude. Si hace todo desde la interfaz, no sabrá qué empleado descontento borró toda la tabla de usuarios por el valor de molestia pura. Si hace todo desde el principio, no sabrá qué dba incompetente ha actualizado accidentalmente todas las órdenes de los clientes al mismo cliente. No puedo admitir el uso de nada más que desencadenantes para la auditoría, ya que, en primer lugar, pierdes una buena parte de por qué necesitas una auditoría.

Answer 4

El uso de interceptores de Hibernate para realizar registros de auditoría es profundamente defectuoso. Estoy sorprendido por la cantidad de blogs que recomiendan este método sin señalar su defecto más obvio: el interceptor TIENE que usar una nueva transacción para registrar la auditoría. Lo que significa que puede salvar con éxito la transacción principal y tener un bloqueo del sistema que no permite registrar la transacción de auditoría.

Answer 5

una vieja pregunta que me atreví a entrar now.There es una opción más disponible y que es Envers que está disponible junto con la hibernación comenzando desde el ver 3.6 en adelante ..

Answer 6

entiendo que esto no es del 100% en relación con el pregunta, pero agrega valor con nuevas opciones.

Hay dos formas más puede auditar lo que está pasando.

lectura de registro de transacciones: Si la base de datos está en modo de recuperación completa a continuación, todos los detalles sobre INSERT, UPDATE, DELETE y sentencias DDL se registran en registro de transacciones.

El problema es que es muy complejo de leer porque no es compatible nativamente y que necesitará un lector de registro de transacciones de terceros como ApexSQL Log o SQL Log Rescue (este último es gratuito pero solo admite sql 2000).

La ventaja de este método es que, literalmente, no tiene que realizar ningún cambio, excepto para poner su base de datos en modo de recuperación completa.

traza de SQL Server: Trazas captarán todo en los archivos de seguimiento que incluye instrucciones select que también puede ser necesario para algunos escenarios de cumplimiento. El inconveniente es que los rastreos son archivos de texto que deben analizarse y organizarse.