Enterprise Data Auditing

Question

Nuestra solución empresarial actual es una aplicación ASP.NET MVC impulsada por Entity Framework. Hay un par de enlaces sobre cómo conectar los eventos de cambio para auditar. No estoy realmente interesado en esto.

Me interesa la arquitectura de auditoría de nivel empresarial. Aquellos de ustedes con las heridas de batalla de nivel empresarial, ¿cuáles han sido sus soluciones de auditoría? ¿Serializa objetos en bases de datos en un marco? ¿Está configurando desencadenadores de base de datos para auditar tablas? ¿Utiliza una base de datos separada para que su crecimiento de auditoría no afecte a la base de datos de su aplicación? Estoy interesado en las soluciones probadas y verdaderas aquí. Sé que hay opciones en nuestra elección de tecnología (EF) pero primero estoy interesado en la base.

Los enlaces serían muy apreciados.

Answer 1

que he visto varias soluciones, pero mi favorita era la simplicidad misma:

• crear tablas de auditoría que Refleje cada tabla fuente, agregue algunas columnas adicionales para rastrear la fecha y el tipo de cambio (insertar, actualizar o eliminar si lo admite) y el usuario que realiza el cambio. Elimine todas las restricciones e índices (a menos que espere realizar muchas búsquedas).

• Dentro de la lógica de actualización de la tabla (utilizamos procedimientos, pero no hay razón para que no se pueda hacer con OR/M u otra capa de persistencia, con los ganchos apropiados), escriba tanto en la tabla fuente como en tabla de auditoría.

Esto tiene numerosos beneficios, pero el más grande (en mi opinión) es no tener que preocuparse o escribir todo el código para gestionar la integridad de las transacciones de las operaciones de escritura emparejados en el cliente.

Answer 2

No tengo ningún enlace, pero en el sistema tengo la alegría de mantener aquí en el trabajo del día. Tenemos una sola tabla de auditoría, que básicamente almacena la siguiente información.

NombreTabla, PrimaryKeyValue, ModifiedColumn, ValorAnterior, NewValue, ChangeUser, Cambiar fecha

Ahora bien, esto funciona muy bien para la velocidad de auditoría, en nuestro código, tenemos una interfaz común para la auto-aplicación del registro de auditoría, pero a partir de un punto de vista de "revisión", no es la forma "más rápida" de recuperar la información. (Admito que en realidad no hemos hecho nada a tener que mirar el registro de auditoría ...)

Answer 3

Recientemente tuvimos que resolver el mismo problema en nuestra empresa. También se nos pidió que pudiéramos volver a versiones anteriores.

Terminamos auditando las entidades comerciales en lugar de las tablas en sql. Básicamente, serializamos los registros en el DB y hacemos un seguimiento de los cambios que se realizan de una versión a la siguiente. Este enfoque nos permite recuperar versiones anteriores en las entidades comerciales y luego revertir llamando a las mismas operaciones de guardado. Esta funcionalidad para revertir se desplazará en la responsabilidad de las aplicaciones porque debe resolverse aquí; de lo contrario, nuestro servicio podría necesitar conocer demasiados detalles sobre las aplicaciones participantes. Se proporcionan operaciones de servicio para recuperar registros por versiones, por fechas, historial de vistas y, por supuesto, para auditar los cambios. Es un enfoque opcional para diferentes grupos de aplicaciones y diferentes entidades (no todo lo que hay en el DB debe ser auditado, entonces ¿por qué hacer eso?).

Luego creamos un sitio web liviano que habla con el servicio y puede mostrar todas las versiones.Creamos un mecanismo para mostrar las adiciones/actualizaciones/eliminaciones para comparar versiones (representación de la interfaz de usuario realmente genial), esto permite a los usuarios ver quién cambió qué y cuándo. El servicio puede devolver un enlace a la url para ver las versiones de una entidad. Esto permite a nuestras aplicaciones webaps + winform/wpf iniciar un navegador para que los usuarios puedan ver los cambios.

Quizás puedo empaquetar esto y proporcionar si alguien está interesado ....