¿Hay alguna biblioteca / marco para deshacer / rehacer cambios de filas en la base de datos?

votos
2

Puede ser que mi título no esté claro. Estoy buscando algún tipo de control de versiones en las tablas de la base de datos, como subversion en los archivos, como lo hace wiki.

Quiero rastrear el registro de cambios. Quiero extraer y ejecutar el diff en reversa. (deshacer como un svn merge -r 101: 100). Es posible que necesite una búsqueda indexada en el historial.

He leído el Patrón de diseño para deshacer el motor , pero está relacionado con Patrones. ¿Hay algo que pueda reutilizar sin reinventar la rueda?

EDITAR: Por ejemplo, transacciones de cuenta bancaria. Tengo el saldo de la columna (y otros) actualizado en la tabla. un usuario encontrará un error suyo 10 días después, y querrá cancelar / deshacer la transacción específica, sin cambiar otras.

¿Cómo puedo hacerlo con gracia en el nivel de aplicación?

Publicado el 09/12/2008 a las 15:08
fuente por usuario
En otros idiomas...                            


7 respuestas

votos
2

Puede usar un enfoque de revisión para cada registro que desee rastrear. Esto implicaría retener una fila en su tabla para cada revisión de un registro. Los registros se unirían mediante una "ID" compartida y podrían consultarse en el "Estado de revisión" (por ejemplo, obtener el último registro "Aprobado").

En su nivel de aplicación, puede manejar estos registros individualmente y volver a un estado anterior si es necesario, siempre que grabe toda la información necesaria.

[ID] [Revision Date] [Revision Status] [Modified By] [Balance]
1     1-1-2008         Expired           User1         $100
1     1-2-2008         Expired           User2         $200
2     1-2-2008         Approved          User3         $300
1     1-3-2008         Approved          User1         $250
Respondida el 09/12/2008 a las 16:40
fuente por usuario

votos
2

Martin Fowler cubre el tema en Patrones de cosas que cambian con el tiempo . Todavía patrones y no un marco real pero muestra datos de ejemplo y cómo usarlos.

Respondida el 09/12/2008 a las 16:19
fuente por usuario

votos
1

Punto pedante El ejemplo de su cuenta bancaria no pasará de un auditor / regulador.

Cualquier entrada errónea en una cuenta debe quedar allí para el registro. Se aplicará una transacción de corrección igual y opuesta a la cuenta. En efecto, se retrotrae la transacción original pero se deja una huella muy obvia del error original y su corrección.

Respondida el 09/12/2008 a las 16:05
fuente por usuario

votos
0

No conozco un patrón específico, aunque he configurado historiales de deshacer / auditoría completos antes de usar desencadenantes y reversiones.

Hay un par de aplicaciones para MS Sql que te permiten navegar por los registros y ver los cambios reales.

He usado uno llamado Log Navigator con MS SQL 2000 que solía permitirme deshacer una transacción histórica específica, aunque ahora no puedo encontrarlo.

http://www.lumigent.com y http://www.apexsql.com hacen herramientas para ver los registros, pero tampoco creo que puedan deshacerse de ellos.

Creo que la mejor manera de hacerlo es escribir su aplicación con esto en mente, que ya tiene un par de buenas sugerencias sobre cómo hacerlo.

Respondida el 10/12/2008 a las 11:20
fuente por usuario

votos
0

Según los diversos comentarios, una posible solución para su problema sería crear una tabla de "fecha efectiva".

Básicamente, agrega columnas válidas desde la fecha y válidas hasta la fecha en cada tabla.

El registro "actual" siempre debe tener una fecha_válida válida de "2999-12-31" o algún valor alto de arbiteraly. Cuando un valor cambia, cambia la fecha "válida hasta la fecha actual" e inserta una nueva fila con una fecha válida de hoy y una copia de "2999-12-31" válida hasta la fecha. columnas de la fila anterior si no se han cambiado.

Puede crear vistas con "select all-columns-except-valid-xx-date from table where valid-to-date = '2999-12-31'"

Lo cual permitirá que todas sus consultas actuales funcionen sin cambios.

Esta es una técnica muy común en entornos de data warehouse y para cosas como los tipos de cambio donde la fecha de vigencia es importante.

La lógica de deshacer debería ser obvia.

Respondida el 10/12/2008 a las 11:07
fuente por usuario

votos
0

Me gustaría ir con un diseño de base de datos bi-temporal, que le daría todos los datos necesarios para realizar y deshacer, ya sea que eso signifique insertar más filas o simplemente eliminar las modificaciones posteriores.

Hay una gran cantidad de sutileza en el diseño de una base de datos, pero hay muy buenos libros sobre el tema:

Desarrollo de aplicaciones de bases de datos orientadas al tiempo en SQL por Richard T. Snodgrass

disponible para descargar aquí:

http://www.cs.arizona.edu/people/rts/tdbbook.pdf

Usar una transacción de base de datos sería una mala idea porque los bloqueos crearían en la base de datos, básicamente las transacciones de la base de datos deberían ser lo más cortas posible.

Cualquier cosa en la capa de aplicación, a menos que tenga algún mecanismo de persistencia, no sobrevivirá a los reinicios de la aplicación (aunque eso podría no ser un requisito).

Respondida el 09/12/2008 a las 18:02
fuente por usuario

votos
0

En función de su comentario a James Anderson, solicitaría a la interfaz de usuario que escriba un nuevo inserto al cancelar una transacción. Insertaría un nuevo registro en la tabla que tenía los mismos valores que la transacción cancelada, excepto que el valor sería un número negativo en lugar de un número positivo. Si tiene una estructura que incluye algo para definir el propósito de la transacción, yo la declararía cancelada y el número de registro de la transacción que estaba cancelando.

Respondida el 09/12/2008 a las 17:05
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more