Formas de tener un historial de cambios en las entradas de la base de datos

¿Cuáles son las formas de permitir el control de versiones de las entradas de la base de datos (datos)?

Piense en las habilidades de los sistemas de gestión de contenido para revertir los cambios de los artículos.

¿Cuáles son sus pros / contras?

Básicamente, hay dos enfoques: una tabla de auditoría, con todos los valores anteriores almacenados en ella, o incluir una fecha de inicio / finalización como parte de la tabla, y todas las actualizaciones crean un nuevo registro mientras se cierra el anterior.

Actualización: SQL SERVER 2016 admite esto como un patrón de diseño / tipo de tabla: https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2017

Una idea es utilizar "Bases de datos de solo inserción". La idea básica es que nunca elimines o actualices datos en una fila .

Cada tabla que se debe rastrear tendrá dos datetimecolumnas fromy to. Comienzan con el valor NULLen cada uno (principio del tiempo hasta el final del tiempo). Cuando necesita "cambiar" la fila, agrega una nueva fila y, al mismo tiempo, actualiza la tofila anterior Nowy fromla fila a la que está agregando Now.

Para obtener información más detallada, consulte:

• Ideas sobre diseño de bases de datos para capturar pistas de auditoría
• ¿El mejor diseño para una tabla de base de datos de registro de cambios / auditoría?

Esta técnica se llama AuditTrailpara administrar datos heredados y almacena un poco el historial de cambios.

Parece que ya se ha publicado una pregunta de esta naturaleza:

• /programming//q/1051449/1437962
• /programming//q/201527/1437962

Creo que puede usar desencadenantes para cada tabla y mantener los datos en _historia (o puede dar cualquier nombre) y en cada inserción, actualización, eliminación en la tabla principal activará su desencadenador y puede guardar los detalles en esta tabla. también está disponible con la base de datos SQLite si está utilizando uno.

Este mecanismo también es útil para grandes proyectos. En esta tabla puede registrar información del usuario que ha realizado los cambios junto con la marca de tiempo de los cambios. luego puede restaurar su tabla a cualquiera de las marcas de tiempo que coincidan con sus requisitos.

Cada base de datos tiene su propia forma de escribir y codificar desencadenantes. Si está utilizando SQLite, visite SQLite.org para obtener la sintaxis. Para otras bases de datos, puede visitar sus sitios oficiales.

Probablemente conozca el motor Sqlite db. Toda la base de datos se guarda en un solo archivo. La API también es compatible con sistemas de archivos virtuales, por lo que básicamente puede organizar el almacenamiento en cualquier lugar y con cualquier formato, simplemente responder a las operaciones de lectura y escritura en desplazamientos de archivos particulares. Las posibles aplicaciones para esto podrían ser cifrado, compresión, etc. La mejor parte es que la capa del contenedor no debe saber nada sobre bases de datos, formato de archivo sql o sqlite, solo obedece las devoluciones de llamada xRead y xWrite.

Una de las ideas era implementar la función de máquina del tiempo. Por lo tanto, cualquier operación de xWrite guarda cada segmento que sobrescribiría en el historial de "deshacer" y el usuario puede elegir una fecha en el pasado para ver qué contenía la base de datos (probablemente en modo de solo lectura). Todavía no tengo un ejemplo de trabajo (hubo una discusión al respecto en la lista de correo sqlite), pero probablemente otros motores suministran API VFS, por lo que es posible algo similar. Y una vez implementado, debería ser compatible con estructuras de bases de datos de cualquier complejidad.

El método que usamos para versionar las entradas de la base de datos es usar una tabla de auditoría. La tabla tiene un esquema en la línea de:

Seq      - Int      ' Unique identifier for this table
Event    - Char     ' Insert / Update / Delete
TblName  - Char     ' Table that had field value changed
FldName  - Char     ' Field that was changed
KeyValue - Char     ' delimited list of values for fields that make up the PK of table changed
UsrId    - Char     ' User who made the change
OldValue - Char     ' Old value (converted to character)
NewValue - Char     ' New value (converted to character)
AddTs    - DateTime ' When the change was made

Luego tenemos activadores en Insertar / Actualizar / Eliminar de las tablas que queremos rastrear.

Pros:

• Todos los datos están en una tabla.
• Se puede configurar para rastrear todos los campos o campos específicos en una tabla
• Versiones fáciles de mostrar en cada campo para una tabla

Contras:

• Tener toda la información de auditoría en una tabla da como resultado un número extremadamente grande de registros
• Se necesitan muchos desencadenantes

Estoy haciendo una versión de esto ahora. para cada registro tengo una fecha insertada, una fecha modificada y una marca booleana de registro activo. Para la inserción inicial, las fechas insertadas y modificadas se establecen en Now () (este ejemplo está en Access) y el indicador de registro activo se establece en true. luego, si modifico ese registro, copio todo a un nuevo registro, cambiando los campos que está cambiando el usuario, dejo la fecha de inserción igual a la original y cambio la fecha de modificación a Ahora (). Luego volteo la bandera de Registro Activo del registro original a falsey el nuevo registro a true. También tengo un campo para ModifiedRecordsParentID donde guardo la identidad del registro original.

Entonces, si incluso necesito consultar, solo puedo devolver los registros donde ActiveRecord = truey solo obtendré la información más actualizada.

Además, si desea almacenar TODOS los cambios en la base de datos a lo largo del tiempo, puede consultar el registro ( /programming/3394132/where-can-i-find-the-mysql-transaction-log )