Estrategias de registro de auditoría

Question

Estoy tratando de decidir cuál es el mejor método para el registro de auditoría dentro de mi aplicación. La razón principal para el registro es informar la secuencia de eventos (cambios).

Tengo una jerarquía de Objetos, necesito crear informes cuando algo cambie en cualquier parte de esa jerarquía, en una fecha posterior.

Creo que tengo tres opciones:

1. Tenga un registro para cada tabla y, por lo tanto, coincida con la jerarquía de objetos y luego cree una vista para el informe.
2. Aplane la jerarquía y des-normalice la tabla, lo que facilita la presentación de informes, simplemente seleccione una declaración.
3. Tenga una tabla de registro y un registro para cada cambio, lo que hace que la presentación de informes sea más difícil pero más flexible a los cambios.

Actualmente me estoy inclinando hacia la opción 1.

Answer 1

Un registro de auditoría es básicamente una lista cronológica de los eventos que ocurrieron, quién realizó estos eventos y cuáles fueron los eventos.

Creo que una vista plana sería mejor, ya que se puede solicitar y consultar fácilmente. Así que me inclino más hacia tu opción # 2 / # 3.

Incluya cosas como el tipo de transacción, la hora, la identificación del usuario, una descripción de lo que ha cambiado y otra información pertinente relacionada con su producto.

También puede agregar elementos a su producto a lo largo del tiempo y no necesitará modificar continuamente su módulo de registro de auditoría.

Answer 2

Tengo que hablar sobre este tema aunque sea antiguo.

Por lo general, es una mala idea tener solo una tabla de auditoría, ya que creará problemas de bloqueo en la base de datos cuando todo llegue a esa tabla. Utilice tablas de auditoría separadas para cada tabla.

También es una mala idea que la aplicación realice la auditoría. La auditoría debe realizarse a nivel de la base de datos o se arriesga a perder parte de la información. Los datos no cambian solo de las aplicaciones en la mayoría de las bases de datos; nadie cambiará los precios de todos sus productos uno por uno desde la interfaz de usuario cuando necesite un aumento del 10% para todos los 10,000,000 de ellos. La auditoría debe capturar todos los cambios, no solo algunos de ellos. Esto se debe hacer en un activador en la mayoría de las bases de datos (SQL Server 2008 tiene una función de auditoría integrada). Algunos de los peores cambios posibles (los empleados que cometen fraude o desean destruir maliciosamente los datos) también suelen provenir de lugares distintos a la aplicación, especialmente si permite el acceso de nivel de tabla a los usuarios (cosa que no debe hacer en ninguna base de datos financiera o que contenga informacion personal). La auditoría desde la aplicación no detectará esto. Los desarrolladores a menudo olvidan que al proteger sus datos, las fuentes externas no son la única amenaza.

Answer 3

Si es para fines de auditoría, usaría un medio de solo apéndice verdadero en lugar de una tabla / tablas en la misma db.

Sugiere que sea para propósitos de historial de cambios, en cuyo caso reestructuraría su aplicación / db para registrar los eventos reales en primer lugar en lugar de solo el estado actual.

Answer 4

Iría con (2) y (3): crear una tabla única para todas las entradas de auditoría.

Una vista plana es buena, siempre que el aplanamiento del trabajo adicional no afecte el rendimiento.

Answer 5

Podrías buscar en un marco AOP para ayudarte con esto. Le permitiría inyectar la funcionalidad de registro al principio o al final de cualquiera o todos los métodos. Si sigue este camino, podría ayudarlo a definir lo que tendría sentido para almacenar los datos de registro.