Pregunta

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

Quiero rastrear el registro de cambios. Quiero extraer y ejecutar el diff en reversa. (deshacer como " 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 motor " ;, pero está relacionado con " Patrones " ;. ¿Hay algo que pueda reutilizar sin reinventar la rueda?

EDITAR: Por ejemplo, transacciones de cuentas bancarias. Tengo la columna & Quot; balance & Quot; (y otros) actualizados en la tabla. un usuario encontrará un error por él 10 días después y querrá cancelar / revertir la transacción específica, sin cambiar otras.

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

¿Fue útil?

Solución

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

Otros consejos

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 estarían unidos por una 'ID' compartida y podrían consultarse en el 'Estado de revisión' (por ejemplo, Obtenga el último & Quot; Aprobado & Quot; record).

En su nivel de aplicación, puede manejar estos registros individualmente y volver a un estado anterior si es necesario, siempre que registre 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

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

Cualquier entrada errónea en una cuenta debe dejarse allí para el registro. Se aplicaría una transacción de corrección igual y opuesta a la cuenta. En efecto, deshace la transacción original pero deja un rastro muy obvio del error original y su corrección.

Según su comentario a James Anderson, la interfaz de usuario escribiría una nueva inserción al cancelar una transacción. Insertaría un nuevo registro en la tabla que tuviera 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, diría que canceló y el número de registro de la transacción que estaba cancelando.

Iría 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 un diseño de base de datos de este tipo, pero hay un libro muy bueno 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 que crearía 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).

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

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

El " actual " el registro siempre debe tener una validez de fecha de " 2999-12-31 " o algún valor arbitrariamente alto. Cuando un valor cambia, cambia & Quot; válido hasta la fecha & Quot; a la fecha actual e inserte un nueva fila con una fecha de inicio de validez de hoy y una fecha de validez de " 2999-12-31 " copie todas las columnas de la fila anterior si no se han cambiado.

Puede crear vistas con " seleccione all-columnas-except-valid-xx-date de la tabla donde valid-to-date = '2999-12-31' "

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

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

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

No conozco un patrón específico, aunque he configurado un historial completo de deshacer / auditar antes de usar disparadores y versiones de fila.

Hay un par de aplicaciones para MS Sql que le permiten rastrear los registros y ver los cambios reales.

He usado uno llamado Log Navigator con MS SQL 2000 que me permitía deshacer una transacción histórica específica; sin embargo, no puedo encontrarla ahora.

http://www.lumigent.com y http://www.apexsql.com hace herramientas para ver los registros, pero no creo que tampoco le permita revertirlos.

Creo que la mejor manera de hacer esto es escribir su solicitud con esto en mente, que ya tiene algunas buenas sugerencias sobre cómo hacerlo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top