¿El mejor diseño para una tabla de base de datos de registro de cambios / auditoría? [cerrado]

Question

Necesito crear una tabla de base de datos para almacenar diferentes registros de cambios / auditorías (cuando algo fue agregado, eliminado, modificado, etc.) No necesito almacenar información particularmente detallada, así que estaba pensando en algo como:

• id (para evento)
• usuario que lo activó
• nombre del evento
• descripción del evento
• marca de tiempo del evento

¿Me estoy perdiendo algo aquí? Obviamente, puedo seguir mejorando el diseño, aunque no planeo hacerlo complicado (crear otras tablas para tipos de eventos o cosas así está fuera de discusión, ya que es una complicación para mi necesidad).

Answer 1

En el proyecto en el que estoy trabajando, el registro de auditoría también comenzó con un diseño muy minimalista, como el que describiste:

event ID
event date/time
event type
user ID
description

La idea era la misma: mantener las cosas simples.

Sin embargo, rápidamente se hizo evidente que este diseño minimalista no era suficiente. La auditoría típica se reducía a preguntas como esta:

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

Entonces, para poder responder rápidamente a estas preguntas (usando SQL), terminamos teniendo dos columnas adicionales en la tabla de auditoría

object type (or table name)
object ID

Ahí es cuando el diseño de nuestro registro de auditoría realmente se estabilizó (por algunos años)

Por supuesto, la última " mejora " Funcionaría solo para tablas que tenían claves sustitutas. ¿Pero adivina que? ¡Todas nuestras mesas que valen la pena la auditoría tienen una clave!

Answer 2

Es posible que desee auditar varias cosas más, como nombres de tablas / columnas, computadora / aplicación desde la cual se realizó una actualización, y más.

Ahora, esto depende de la auditoría detallada que realmente necesite y a qué nivel.

Comenzamos a construir nuestra propia solución de auditoría basada en disparadores, y queríamos auditar todo y también tener una opción de recuperación a la mano. Esto resultó ser demasiado complejo, por lo que terminamos aplicando ingeniería inversa a la herramienta de terceros basada en el activador ApexSQL Auditoría para crear nuestra propia solución personalizada.

Consejos:

• Incluir valores de antes / después

• Incluya 3-4 columnas para almacenar la clave principal (en caso de que se trate de una clave compuesta)

• Almacene datos fuera de la base de datos principal como ya lo sugirió Robert

• Pase una cantidad de tiempo decente en la preparación de informes & # 8211; especialmente aquellos que pueda necesitar para la recuperación

• Plan para almacenar el nombre del host / aplicación & # 8211; esto podría ser muy útil para rastrear actividades sospechosas

Answer 3

También registramos los valores antiguos y nuevos y la columna de la que son, así como la clave principal de la tabla que se audita en una tabla de detalles de auditoría. ¿Piensas para qué necesitas la mesa de auditoría? No solo desea saber quién hizo un cambio y cuándo, sino que, cuando se produce un cambio malo, desea una forma rápida de volver a colocar los datos.

Mientras está diseñando, debe escribir el código para recuperar datos. Cuando necesita recuperarse, generalmente tiene prisa, lo mejor es que ya esté preparado.

Answer 4

Hay muchas respuestas interesantes aquí y en preguntas similares. Las únicas cosas que puedo agregar de mi experiencia personal son:

1. Coloque su tabla de auditoría en otra base de datos. Lo ideal es que se separe de los datos originales. Si necesita restaurar su base de datos, realmente no desea restaurar la pista de auditoría.

2. Desnormalizar tanto como sea razonablemente posible. Desea que la tabla tenga la menor cantidad de dependencias posible para los datos originales. La tabla de auditoría debe ser simple y muy rápida para recuperar datos. No hay combinaciones ni búsquedas sofisticadas en otras tablas para obtener los datos.

Answer 5

Lo que tenemos en nuestra mesa: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

La identificación genérica apunta a una fila en la tabla que se actualizó y el nombre de la tabla es el nombre de esa tabla como una cadena. No es un buen diseño de base de datos, pero es muy útil. Todas nuestras tablas tienen una única columna de clave sustituta, por lo que esto funciona bien.

Answer 6

Hay muchas maneras de hacer esto. Mi forma favorita es:

1. Agregue un campo mod_user a su tabla fuente (la que desea registrar).

2. Cree una tabla de registro que contenga los campos que desea registrar, más un campo log_datetime y seq_num . seq_num es la clave principal.

3. Cree un desencadenante en la tabla de origen que inserte el registro actual en la tabla de registro cada vez que se cambie un campo supervisado.

Ahora tienes un registro de cada cambio y de quién lo hizo.

Answer 7

En general, la auditoría personalizada (crear varias tablas) es una mala opción. Los activadores de base de datos / tabla se pueden desactivar para omitir algunas actividades de registro. Las tablas de auditoría personalizadas pueden ser manipuladas. Pueden producirse excepciones que harán caer la aplicación. No menciona dificultades para diseñar una solución robusta. Hasta ahora veo un caso muy simple en esta discusión. Necesita una separación completa de la base de datos actual y de cualquier usuario privilegiado (DBA, Desarrolladores). Todos los RDBMS principales proporcionan servicios de auditoría que incluso los DBA no pueden deshabilitar, alterar el secreto. Por lo tanto, la capacidad de auditoría proporcionada por el proveedor de RDBMS debe ser la primera opción. Otra opción sería un lector de registro de transacciones de terceros o un lector de registro personalizado que inserta información descompuesta en el sistema de mensajería que termina en algunas formas de Audit Data Warehouse o un controlador de eventos en tiempo real. En resumen: Solution Architect / " Hands on Data Architect " debe involucrarse en el destino de un sistema de este tipo basado en los requisitos. Por lo general, es algo demasiado serio como para entregarlo a los desarrolladores para una solución.

Answer 8

Según el principio de separación:

1. Las tablas de datos de auditoría deben estar separadas de la base de datos principal. Dado que las bases de datos de auditoría pueden tener muchos datos históricos, tiene sentido desde el punto de vista de la utilización de la memoria mantenerlos separados.

2. No use los activadores para auditar toda la base de datos, ya que terminará con un lío de diferentes bases de datos para admitir. Deberá escribir uno para DB2, SQLServer, Mysql, etc.

Answer 9

Llegó tarde a la fiesta, pero recomiendo el proyecto de auditoría automática .
Es 100% gratis y de código abierto. Es creado por los MVP de SQL, Paul Nielsen y John Sigouin. Es muy estable y actualmente está en la versión 3.30.

Fácil de instalar. Simplemente ejecute el SP que proporcionan. Creará un esquema de auditoría, algunos SP de mantenimiento y los activadores necesarios para realizar la auditoría. A partir de ahí, simplemente elija qué tablas desea auditar y con qué detalle.