Estrategias de registro de auditoría

Question

Estoy tratando de decidir sobre 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 cambia en cualquier parte de esa jerarquía, en una fecha posterior.

creo que tengo tres opciones:

1. tener un registro para cada mesa de juego y por lo tanto la jerarquía de objetos a continuación, crear una vista para el informe.
2. Allanar la jerarquía y desnormalizar la tabla, facilitando los informes - simple instrucción de selección.
3. Tiene una tabla de registro y tiene un registro para cada cambio, lo que hace que los informes sean más difíciles pero más flexibles a los cambios.

actualmente estoy inclinando hacia la opción 1.

Answer 1

un registro de auditoría es básicamente una lista cronológica de los hechos ocurridos, que llevaron a cabo estos eventos, y lo que los eventos fueron.

Creo que una vista plana sería mejor ya que puede ordenarse e interrogarse fácilmente. Así que me estoy inclinando más hacia su 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 cosas a su producto con el tiempo y no tendrá que modificar continuamente su módulo de registro de auditoría.

Answer 2

Si es para fines de auditoría, utilizaría un verdadero medio de solo anexar en lugar de una tabla/tablas en el mismo archivo base.

Usted sugiere que sea para el historial de cambios, en cuyo caso yo reestructuraría su aplicación/base de datos para registrar los eventos reales en primer lugar en lugar de solo el estado actual.

Answer 3

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

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

Answer 4

Puede consultar un marco AOP para ayudar con esto. Le permitiría inyectar la funcionalidad de registro al principio o al final de cualquiera o de todos los métodos. Si avanza por este camino, podría ayudar a definir qué tendría sentido para almacenar los datos de registro.

Answer 5

Tengo que hablar sobre este tema a pesar de que es viejo.

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 ya que todo golpea esa tabla. Use tablas de auditoría separadas para cada tabla.

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