Versioning Database Persisted Objects, ¿Cómo lo harías?
database-design (8)
(No relacionado con el control de versiones del esquema de la base de datos)
Las aplicaciones que interactúan con bases de datos a menudo tienen objetos de dominio que se componen con datos de muchas tablas. Supongamos que la aplicación fuera compatible con el control de versiones, en el sentido de CVS, para estos objetos de dominio.
Para algún objeto de dominio arbitrario, ¿cómo diseñaría un esquema de base de datos para manejar este requisito? ¿Alguna experiencia para compartir?
Necesitará un registro maestro en una tabla maestra que contenga la información común entre todas las versiones.
A continuación, cada tabla secundaria utiliza el ID del registro maestro + versión no como parte de la clave principal.
Se puede hacer sin la tabla maestra, pero en mi experiencia tenderá a hacer que las sentencias SQL sean mucho más complicadas.
Piense cuidadosamente sobre los requisitos para las revisiones. Una vez que su base de código tenga un seguimiento de historial generalizado integrado en el sistema operativo, se volverá muy complejo. Insurance systems underwriting Insurance son particularmente malos para esto, con esquemas que a menudo superan las 1000 tablas. Las consultas también tienden a ser bastante complejas y esto puede generar problemas de rendimiento.
Si el estado histórico realmente solo es necesario para la generación de informes, considere implementar un sistema transaccional de "estado actual" con una estructura de data warehouse colgando hacia atrás para el historial de seguimiento. Las dimensiones que cambian lentamente son una estructura mucho más sencilla para rastrear el estado histórico que tratar de incorporar un mecanismo de seguimiento de historial ad-hoc directamente en su sistema operativo.
Además, la Captura de datos modificada es más simple para un sistema de ''estado actual'' y se realizan cambios en los registros: las claves principales de los registros no cambian, por lo que no es necesario que coincida con registros que contengan versiones diferentes de la misma entidad. juntos. Un mecanismo efectivo de CDC hará que un proceso de carga de almacén incremental sea bastante ligero y posible de ejecutar con bastante frecuencia. Si no necesita un seguimiento minuto a minuto del estado histórico (casi, pero no del todo, y oxímoron), esta puede ser una solución efectiva con una base de código mucho más simple que un mecanismo completo de seguimiento del historial integrado directamente en la aplicación.
Si está utilizando Hibernate, JBoss Envers podría ser una opción. Solo tiene que anotar las clases con @Audited para mantener su historial.
Una alternativa al control de versiones estrictas es dividir los datos en 2 tablas: actual e historial.
La tabla actual tiene todos los datos en tiempo real y tiene los beneficios de todo el rendimiento que usted construye. Cualquier cambio primero escribe los datos actuales en la tabla de "historial" asociada junto con un marcador de fecha que indica cuándo cambió.
Una forma simple e infalible es agregar una columna de versión a sus tablas y almacenar la versión del Objeto y elegir la lógica de aplicación adecuada en función de ese número de versión. De esta manera también obtienes compatibilidad con versiones anteriores a un bajo costo. Lo cual siempre es bueno
Una técnica que he usado para esto en el pasado ha sido tener un concepto de "generaciones" en la base de datos, cada cambio incrementa el número de generación actual para la base de datos: si usa la subversión, piense en las revisiones. Cada registro tiene 2 números de generación asociados (2 columnas adicionales en las tablas): la generación para la que el registro comienza a ser válido y la generación para la que deja de ser válida. Si los datos son actualmente válidos, el segundo número sería NULL o algún otro marcador genérico.
Entonces para insertar en la base de datos:
- incrementar el número de generación
- inserta los datos
- marque la duración de esos datos con valid from, y valid to of NULL
Si está actualizando algunos datos:
- marque todos los datos que están a punto de modificarse como válidos para el número de generación actual
- incrementar el número de generación
- inserte los datos nuevos con el número de generación actual
eliminar es solo una cuestión de marcar los datos como terminando en la generación actual.
Para obtener una versión particular de los datos, encuentre la generación que busca y busque datos válidos entre esas versiones de generación.
Ejemplo:
Crea una persona.
|Name|D.O.B |Telephone|From|To |
|Fred|1 april|555-29384|1 |NULL|
Actualizar tel no.
|Name|D.O.B |Telephone|From|To |
|Fred|1 april|555-29384|1 |1 |
|Fred|1 april|555-43534|2 |NULL|
Eliminar fred:
|Name|D.O.B |Telephone|From|To |
|Fred|1 april|555-29384|1 |1 |
|Fred|1 april|555-43534|2 |2 |
Una vez que un objeto se guarda en una base de datos, podemos modificar ese objeto en cualquier momento. Si queremos saber cuántas veces se modifica un objeto, entonces debemos aplicar este concepto de control de versiones.
Cuando alguna vez utilizamos el control de versiones, hibernate inserta el número de versión como cero, cuando el objeto se guarda por primera vez en la base de datos. Más tarde hibernate aumenta esa versión no por uno automáticamente cuando se realiza una modificación en ese objeto en particular. Para utilizar este concepto de control de versiones, necesitamos los siguientes dos cambios en nuestra aplicación
Add one property of type int in our pojo class.
In hibernate mapping file, add an element called version soon after id element
ZoDB + ZEO implementa una base de datos basada en revisión con reversión completa a cualquier soporte puntual. Ve a verlo.
Mala parte: está atada Zope.