¿La mejor manera de diseñar una base de datos y una tabla para mantener registros de los cambios?

16

Necesito configurar una función de historial en un proyecto para realizar un seguimiento de los cambios anteriores.

Digamos que tengo dos tablas en este momento:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Ejemplo: tengo una fila en las notas y el usuario quiere cambiar el mensaje. Quiero hacer un seguimiento de su estado antes del cambio y después del cambio.

¿Cuál sería el mejor enfoque para configurar una columna en cada una de estas tablas que dirá si un elemento es "viejo"? 0 si está activo O 1 si está eliminado / invisible.

También quiero crear una AUDIT TRAILtabla history ( ) que contenga la iddel estado anterior, la iddel nuevo estado, ¿con qué tabla se relacionan estos id?

mysql database-design audit

— Schwarz
fuente

1

Puede usar desencadenantes de bases de datos para crear una tabla de auditoría .

— Kin Shah

5

Por favor ver

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

Es una muy buena lectura sobre los enfoques para crear un Audit Trail en el diseño de su base de datos. Las pistas de auditoría son necesarias para la implementación de una base de datos. Siempre debe poder ver las acciones de los usuarios de la base de datos dentro del sistema.

Podemos realizar un seguimiento de las filas que se modificaron en nuestro sistema PTA (punto en el tiempo) agregando algunas columnas estándar PTA (punto en el tiempo) a todas las tablas de interés de la PTA.

Sugiero lo siguiente:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

— Héctor
fuente

cuál es la mejor manera de aplicar la 'Solución n. ° 2: Tabla de seguimiento de datos dedicada' para una aplicación OLTP.

— AA.SC

La compañía para la que trabajo actualmente usa múltiples esquemas, uno específicamente para el seguimiento de auditoría. La tabla de auditoría realmente es un diseño bastante simple cuando se usa la Solución # 2 (que es exactamente lo que usamos aquí en el trabajo). Desglose las diferentes tareas (tabla de inventario actualizada, información del cliente actualizada o eliminada, créditos otorgados al cliente, etc., etc.) y construya la tabla de auditoría basada en acciones comunes que los usuarios son capaces de realizar. ¿Responde eso a su pregunta con respecto a la aplicación de la solución 2 a su base de datos? Si no, aclare. ¡Gracias!

— Héctor

En realidad, ya estamos auditando datos con el primer enfoque usando las tablas de auditoría, pero los datos de auditoría se están volviendo tan grandes y ahora queremos convertir nuestro enfoque simplemente capturando datos en columnas cambiadas. Mi pregunta es ¿cómo puedo lograr este enfoque? ¿Cuál es la mejor manera de rastrear qué columna de la tabla se cambia? .. si una tabla tiene más de 20 columnas, una de ellas es con Texto de tipo de datos.

— AA.SC

10

Al diseñar capacidades de control de versiones en sus datos, hay varios requisitos mínimos (creo):

Cada versión de los datos debe ser autónoma e independiente de otras versiones. Esto significa que no hay bandera u otro indicador que muestre cuál es la versión actual y cuál es "historial". También significa actualizar la entidad significa insertar solo una nueva versión, no es necesario actualizar las versiones anteriores.
Evite lo que yo llamo dependencia de extensión de fila Ahí es donde un campo (End_Date) de una fila debe permanecer sincronizado con otro campo (Start_Date) de una fila diferente. Esto hace que trabajar con los datos sea más difícil y es una excelente fuente de anomalías.
La versión actual y todas las versiones anteriores deben estar en la misma tabla. Esto permite utilizar la misma consulta para ver datos pasados "a partir de" una fecha particular y para ver los datos actuales.
Las claves externas para los datos que se han versionado deberían funcionar igual que los datos normales (no versionados).
El diseño debe ser tan simple o universalmente entendido que la curva de aprendizaje para los nuevos desarrolladores se minimice.

Aquí están las diapositivas de una presentación que hice varias veces en ferias tecnológicas. Cubre cómo se puede hacer todo lo anterior. Y aquí hay un documento que entra en más detalles. Debo pedir disculpas por el documento: es un trabajo en progreso y no todas las secciones están completas. Pero debería darle toda la información necesaria para implementar cualquier cosa, desde versiones simples hasta acceso bi-temporal completo.

— TommCatt
fuente

1

Muy buenos puntos! Sin embargo, no entiendo muy bien esto This means no flag or other indicator showing which is the current version and which are "history.", si no hay indicador o indicador, ¿cómo diferenciamos la versión actual de la versión del historial? Sobre todo en función de su tercer punto, que sugiere que deberían estar en la misma tabla.

— GMsoF

La presentación muestra un diseño de ejemplo, que incluye la consulta para leer datos actuales y / o pasados de las tablas. Si parece lo suficientemente interesante como para profundizar, el documento contiene muchos más detalles.

— TommCatt