Actualmente quiero estructurar una tabla de seguimiento / historial como esta:
- PrimaryKey - ID
- OtherTableId - fk
- fieldName: nombre del campo que sigue
- Valor antiguo
- Nuevo valor
- Nombre de usuario
- CreateDateTime
Entonces, básicamente, quiero tener una tabla que rastree el historial de otras tablas, almacene el nombre de columna del campo modificado con el valor nuevo y antiguo. Mi pregunta es ¿alguien puede hacer agujeros en esto? Además, ¿cuál es la forma más fácil de garantizar que solo se ingrese un nombre de columna de las tablas de seguimiento en la columna fieldName? Actualmente, mis opciones son tener una enumeración en el servicio que estoy construyendo, o crear otra tabla de estado y hacer que fieldName sea un fk. ¿Alguna idea mejor?
Editar objetivo: actualmente solo hay 2 campos que queremos rastrear. Un campo se mostrará en una página web para mostrar el historial, al otro campo solo accederá un departamento y ellos tendrán acceso a una vista de la base de datos que podrán consultar. Estarían consultando solo este campo para obtener información sobre quién cambió el campo y qué hacer. Esta es la razón por la que queríamos establecerlo donde un campo de base de datos define la columna de la tabla en lugar de tener una copia exacta del historial de registros de la tabla. Solo queremos rastrear dos campos con la posibilidad de agregar o eliminar campos en el futuro.
¡Gracias!
Respuestas:
Hacer agujeros: ¿qué pasa si el esquema de la base de datos se cambia en el mismo punto más adelante en el tiempo, y el nombre de una columna cambia o la columna se elimina por completo? Muchos sistemas de bases de datos lo permiten. ¿Qué pasará con su "fieldName" entonces?
Para la integridad de los datos: debe asegurarse de que cada operación de actualización o eliminación seguramente actualizará su tabla de seguimiento. Esto se logra mejor mediante disparadores que llaman a un procedimiento almacenado. Debe asegurarse de que solo los procedimientos almacenados tengan acceso de escritura a su tabla de seguimiento, para que nadie más pueda escribir valores incorrectos.
Si puede vivir con una solución específica de proveedor de base de datos: la mayoría de los sistemas de base de datos tienen tablas del sistema donde se almacena la información del esquema (nombres de tabla, identificadores de tabla, nombres de columna, etc.). Puede verificar si es posible establecer una referencia de clave externa para dicha tabla del sistema. Eso permitiría reemplazar el nombre del campo por una ID de campo si la base de datos admite algo como esto.
En realidad, si necesita rastrear filas completas de la tabla específica, incluidas todas las columnas (y no solo un pequeño subconjunto de las columnas), debe considerar la sugerencia de @ sarfeast. Lea este artículo sobre los inconvenientes de los modelos de pares de nombre-valor.
fuente
La implementación de la auditoría de cambios (seguimiento de historial) más exitosa que he visto es menos genérica y mucho más simple. Implica crear una tabla de registro de cambios para cada tabla que desee supervisar, manteniendo nombres de columna y tipos de datos idénticos (con una columna adicional para la marca de tiempo).
El objetivo final, es decir, lo que le gustaría hacer con los datos auditados ayudará a evaluar qué tan adecuado puede ser cada enfoque.
fuente
En resumen: debe configurar el mecanismo de seguimiento de auditoría para las tablas en las que desea realizar un seguimiento del cambio de valor.
Tabla de seguimiento de auditoría única :
Aquí hay una buena publicación con scripts sobre cómo lograrlo: crear pistas de auditoría
Otras referencias útiles para mirar:
fuente
Es posible que desee consultar la documentación del proyecto NHibernate Envers para obtener ideas.
Básicamente, tiene una tabla de revisión donde puede agregar datos adicionales como una marca de tiempo o un usuario. Luego, cada tabla que rastrea obtiene una tabla de auditoría adicional con todas las columnas duplicadas, un fk a la tabla de revisión y el tipo de revisión (agregar, modificar, eliminar). AFAIK, no querría que sus tablas de auditoría tengan un FK real en la tabla real porque eso evitaría eliminaciones.
fuente