¿Cómo utilizaría un seguimiento de auditoría para mostrar qué campos se han editado alguna vez?

Question

Para un proyecto en el que estoy trabajando, se me ha pedido que cree una pista de auditoría de todos los cambios que se hayan realizado en los registros. Esta es la primera vez que tengo que crear una pista de auditoría, así que he estado investigando mucho sobre el tema.

La aplicación se desarrollará en PHP/MSSQL, y será de poco tráfico.

Según he leído, he decidido tener una tabla de auditoría y usar activadores para registrar los cambios en la tabla.

Los dos requisitos para su visualización en la aplicación son los siguientes:

1. podrá ver un registro de todos los cambios realizados en un campo (yo más o menos sé cómo hacer esto)

2. Poder ver, al ver un registro en la aplicación, un indicador al lado de cualquier campo en el registro que haya sido modificado (y posiblemente otra información como la fecha del último cambio).

El artículo n. ° 2 es el que actualmente me está causando dolor. Sin hacer una consulta separada para cada campo (o una consulta anidada muy larga que tardará años en ejecutarse), ¿alguien tiene sugerencias para una forma óptima de hacerlo? (He pensado en agregar un campo adicional "ModifiedFlag" para cada campo de la tabla, que actuará como indicador booleano si el campo alguna vez se ha editado, pero eso parece una gran sobrecarga.

Answer 1

Me gustaría tratar el información de auditoría por separado de la información de dominio real tanto como sea posible

Requisito # 1:.. Creo que va a crear tablas de auditoría adicionales para registrar los cambios Eric sugerencia es buena, la creación de la información de auditoría utilizando desencadena en la base de datos SQL. De esta forma, su aplicación no necesita conocer la lógica de auditoría.

Si su base de datos no admite activadores, entonces quizás esté utilizando algún tipo de persistencia o capa de base de datos. Este también sería un buen lugar para poner este tipo de lógica, ya que de nuevo minimiza cualquier dependencia entre normal código de aplicación y el código de auditoría.

Requisito 2: En cuanto a los indicadores que muestran: Yo no crear campos booleanos en la tabla que almacena la real. (Esto causaría que existen todo tipo de dependencias entre el código aplicación normal y su pista de auditoría de código.)

me gustaría tratar de dejar que el código responsable de mostrar el formulario también se encargará de mostrar los datos de auditoría de nivel de campo. Esto causará sobrecarga de consultas, pero ese es el costo de mostrar esta capa adicional de información. Tal vez pueda minimizar la sobrecarga de la base de datos agregando metadatos a la información de auditoría que permita una fácil recuperación.

Algunas aplicaciones Enterprisy grande que mantengo utiliza más o menos la siguiente estructura:

• Una mesa de modificación de la cabecera correspondiente a un cambio de un registro en una tabla.

campos:

changeId, changeTable, changedPrimaryKey, userName, dateTime 

- Una tabla de campos cambio correspondiente a un campo que se cambia.

campos: contenido

changeId, changeField, oldValue, NewValue 

muestra:

modificación de la cabecera:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30' 

Cambio artículo:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy' 
'1', 'Author', 'Duglas Adasm', 'Douglas Adams' 

Esta estructura permite una fácil visualización de los registros de auditoría, así como una recuperación fácil para mostrar los indicadores deseados. Una consulta (unión interna en la tabla de encabezado y elementos) sería suficiente para recuperar toda la información para mostrar en un solo formulario. (O incluso una tabla cuando tiene una lista de Id. Mostrados)

Answer 2

Como requisito general, marcar el campo cambiado "huele" ligeramente extraño. Si los registros son de larga vida y están sujetos a cambios a lo largo del tiempo, eventualmente todos los campos tenderán a marcarse así. Por lo tanto, me pregunto cómo cualquier usuario podría tener sentido de un simple conjunto de indicadores por campo.

Esa línea de pensamiento me hace sospechar que los datos que almacena deben ser, como usted ha descrito, una verdadera pista de auditoría con todos los cambios registrados, y el primer desafío real es decidir cómo debe presentarse la información para el usuario.

Creo que su idea de preparar algún tipo de datos agregado de TheAuditTrail es muy útil. La pregunta sería ¿es suficiente un solo indicador por registro? Si el acceso principal del usuario es a través de la lista, entonces tal vez sea suficiente solo para resaltar los registros modificados para un desglose posterior. O una fecha del último cambio del valor del registro, de modo que solo se resalten los registros modificados recientemente, todo de acuerdo con las necesidades reales del usuario. Me resulta difícil imaginar que los registros cambiados hace 3 años sean tan interesantes como los que cambiaron la semana pasada.

Luego, cuando lleguemos a la exploración de un solo registro. De nuevo, un simple indicador por campo no suena útil (aunque su dominio, sus requisitos). Si es así, entonces su idea de resumen está bien. Supongo que una secuencia de cambios en un campo y la secuencia de cambios generales en el registro son mucho más interesantes. El empleado tuvo aumento de sueldo, el departamento se mudó del empleado, el empleado fue promovido = tres eventos comerciales separados o uno?

Si se necesita algo más que una simple bandera, entonces sospecho que solo necesita devolver la pista de auditoría completa (o reciente) para el registro y dejar que la UI descubra cómo presentarla.

Entonces, mi pensamiento inicial: Algún tipo de mantenimiento gradual de un registro de resumen parece una buena idea. Si es necesario, manténgalo en subprocesos de fondo o trabajos por lotes. Pensamos que es útil para el negocio sin tener que ir a la pista de auditoría completa cada vez. Luego, para análisis detallados, permitimos que se recupere parte o la totalidad del camino.

Answer 3

Personalmente, haría el seguimiento simple, y el informe de funky.

Cada vez que un usuario inserta un registro, se hace una inserción en la tabla de auditoría para esa tabla

'I', 'Date', 'User', 'Data column1','Data Column2', etc. 

que está asumiendo la estructura de las tablas no va a cambiar con el tiempo (re. La cantidad de DataColumns)

Para actualizaciones, basta con insertar

'U', 'Date', 'User', 'Data column1', etc 

insertar lo que el usuario acaba de entrar como una actualización.

Luego, después de la inserción y actualización, que tendrá la siguiente

'I','May 3 2009','BLT','person005','John','Smith','Marketing' 
'U','May 4 2009','BLT','person005','John','Smith','Accounting' 

Entonces, es sólo un informe fácil demostrar que el registro persona única 'person005' ha tenido una inserción y una actualización, en donde su departamento fue actualizado.

Debido al bajo uso del sistema, tener una inserción simple en el cambio, entonces un proceso de informe más complejo no va a afectar el rendimiento. Este estilo seguirá funcionando con sistemas de tráfico más altos, ya que la carga adicional de una edición es mínima, mientras que la carga de trabajo de mayor intensidad para informar los cambios no se realiza con tanta frecuencia como una actualización, por lo que el sistema no se caerá.