La implementación de Auditoría TRAIL primavera AOP vs.Hibernate Interceptor vs DB gatillo

Question

He encontrado par de hilos de discusión en esto- pero nada que trajo una comparación de los tres mecanismos bajo un mismo hilo.

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

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

No puedo pensar en tres maneras de hacer esto

1) DB Triggers

2) Hibernate interceptores

3) Spring AOP

(Esta pregunta es específica de una primavera \ Hibernate \ RDBMS- supongo que esto es neutral a java \ C # o hibernación \ nhibernate- pero si su respuesta depende de C ++ o Java o aplicación específica de hibernate especificar)

¿Cuáles son los pros y los contras de la selección de una de estas estrategias?

No estoy pidiendo implementación details.-Esta es una discusión diseño.

Estoy esperando que podemos hacer esto como una parte de la comunidad wiki

Answer 1

Sólo puedo hablar de disparadores y NHibernate, porque yo no lo sé suficientes Abou tSpring AOP.

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

DB disparadores

• son rápidos
• siempre son llamados, incluso de SQL nativo, secuencias de comandos, aplicaciones externas.
• escritura de datos en la base de datos de los que NH no sabe nada. Estará ausente en la sesión actual. (Lo que podría conducir a resultados inesperados)
• do por lo general no sabe nada acerca de su sesión. (Por ejemplo: nombre de inicio de sesión)

interceptores NHibernate / eventos

• No se DBMS específico.
• permite acceder fácilmente a la información que los negocios, al igual que la sesión de usuario, nombre de la máquina cliente, ciertos cálculos o interpretaciones, localización, etc.
• que permite la configuración declarativa, como atributos en la entidad, que definen si la entidad tiene que estar conectado y cómo.
• permitirá apagar el registro, esto podría ser importante para las actualizaciones, las importaciones, las acciones especiales que no son desencadenadas por el usuario.
• que permitirá una vista entidad para el modelo de negocio. Usted probablemente está más cerca del punto de vista del usuario.

Answer 2

Entiendo que esto no es 100% en relación con la pregunta, pero se le añade 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 para leer porque no es compatible de forma nativa y que necesitará un tercer lector de registro de transacciones parte, como ApexSQL Log o SQL Log de rescate (el último es libre, pero sólo es compatible con 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.

trazas 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. La desventaja es que los rastros son archivos de texto que deben ser analizados y organizados.

Answer 3

No puedo pensar en ninguna buena razón para no usar la base de datos activa para auditar los cambios en la base de datos. Inserciones, actualizaciones y eliminaciones potencialmente pueden golpear la base de datos de varias fuentes - desencadenantes cogerán todo esto; Hibernate etc. voluntad no.

Answer 4

Me tink si tenemos en cuenta la auditoría, debe tener en cuenta lo que es para. En primer lugar, es a havea registro de quién cambió qué y lo que ha cambiado para que pueda retirarse malos cambios, puede identificar problemas con el sistema (podemos ver cuál de las varias aplicaciones diferentes personas casued el cambio que ayuda a identificar rápidamente cuál se rompe) y para que pueda identificar quién hizo el cambio. El último puede ser muy crítico cuando se trata de detectar el fraude. Si lo hace todo, desde la interfaz de usuario, que nunca se verá el fraude cometer usuario que cambia los datos en el backend para escribir un cheque a sí mismo. Si lo hace todo, desde la interfaz, probablemente usted tiene que tener permisos establecidos a nivel tabel, abriendo así la puerta al fraude, para empezar. Si lo hace todo, desde la interfaz que no sabrá qué empleado descontento borra toda la tabla de usuario para el valor puro enfado. Si lo hace todo, desde la parte delantera no sabrá lo que dba incompetente actualiza accidentalmente todos los pedidos de los clientes al mismo cliente. No puedo apoyar el uso de cualquier cosa excepto desencadenantes de auditoría a medida que pierde una buena parte de por qué necesita la auditoría en el primer lugar.

Answer 5

Uso de interceptores de Hibernate para realizar registros de auditoría es profundamente defectuoso. Estoy sorprendido por el número de blogs que recomiendan este método sin señalar su defecto más evidente - el interceptor tiene que utilizar una nueva transacción para registrar la auditoría. Lo que significa que podría ahorrar con éxito la operación principal y tiene un fallo del sistema que no logra registrar la transacción de auditoría!

Answer 6

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 ..