database - Gestionar la migración de los cambios de la base de datos en una base de datos compartida por la versión anterior de la misma aplicación

architecture deployment (4)

Lea el libro de Scott Ambler " Refactorización de bases de datos "; tomar con una pizca de sal, pero hay un montón de buenas ideas allí.

Los detalles de las soluciones disponibles dependen del DBMS que use. Sin embargo, puedes hacer cosas como estas:

crear una nueva tabla (o varias tablas nuevas) para el nuevo diseño
crear una vista con el nombre de la tabla anterior que recopila datos de la (s) nueva (s) tabla (s)
crear desencadenantes ''en vez de'' en la vista para actualizar las nuevas tablas en lugar de la vista

En algunas circunstancias, no necesita una nueva tabla, es posible que solo necesite desencadenantes.

Uno de mis objetivos es poder implementar una nueva versión de una aplicación web que se ejecute al lado de la versión anterior. El problema es que todo comparte una base de datos. Una base de datos que en la nueva versión tiende a incluir una refactorización significativa en las tablas de la base de datos. Me gustaría implementar la nueva versión de la aplicación para los usuarios a lo largo del tiempo y poder volver a cambiarla a la versión anterior si es necesario.

Oren tuvo una buena publicación al configurar el problema, pero terminó con:

"Todavía estamos en aguas fangosas con respecto a la implementación en producción en lo que respecta a los cambios que afectan a todo el sistema, es decir, a los cambios en la base de datos. Voy a discutir eso en la próxima entrega, este solo tiene un poco de mano, tengo miedo ".

La publicación de seguimiento nunca llegó ;-). ¿Cómo haría para gestionar la migración de los cambios de bases de datos en una base de datos compartida por la versión anterior de la misma aplicación? ¿Cómo mantendría sincronizados los datos?

Si se debe mantener la versión anterior, los cambios simplemente no se pueden romper. Eso también ayuda al implementar una nueva versión de una aplicación web: si necesita retroceder, realmente ayuda si puede dejar la base de datos tal como está.

Obviamente, esto viene con importantes desventajas arquitectónicas, y es casi seguro que terminará con una base de datos que muestra su linaje, por así decirlo, pero los beneficios de la implementación por lo general valen los dolores de cabeza, en mi experiencia.

Ayuda si tiene una colección sólida de pruebas de integración para cada versión anterior involucrada. Debería poder ejecutarlos en su base de datos de prueba migrada para cada versión que todavía se considere "posiblemente en vivo", que bien podría ser "todas las versiones" en algunos casos. Si puede controlar el despliegue de forma razonablemente estricta, puede salirse con la suya solo teniendo compatibilidad con tres o cuatro versiones, en cuyo caso puede planear la eliminación de tablas / columnas obsoletas, etc., si es realmente necesario. Solo tenga en cuenta la complejidad de dicha planificación en comparación con los beneficios acumulados.

Suponiendo solo 2 versiones de su cliente, solo mantendría una copia de los datos en las nuevas tablas.

Puede mantener el contrato entre las aplicaciones antiguas y las nuevas detrás de las vistas en la parte superior de las nuevas tablas. Utilice antes / en lugar de desencadenantes para manejar escrituras en las vistas "antiguas" que realmente escriben en las tablas nuevas.

Está manteniendo 2 versiones de código y aún debe desarrollar su aplicación anterior, pero es inevitable.

De esta forma, no hay problemas de sincronización, de manera efectiva tendría que lidiar con conflictos de replicación entre esquemas "antiguos" y "nuevos".

Más de 2 versiones se complican como se mencionó ...

Primero, me gustaría decir que este problema es muy difícil y es posible que no encuentre una respuesta completa.

Últimamente he estado involucrado en el mantenimiento de una línea heredada de aplicaciones comerciales, que pronto podría evolucionar a una nueva versión. El mantenimiento incluye la solución de errores, la optimización del código antiguo y las nuevas características, que a veces no se ajustan fácilmente a la arquitectura de la aplicación actual. El principal problema con nuestra aplicación es que estaba mal documentada, no hay ningún rastro de cambios y básicamente somos el quinto equipo de rotación que trabaja en este proyecto (somos bastante nuevos).

Dejando los detalles externos en el lateral (código, capas, etc.), intentaré explicar un poco cómo estamos gestionando actualmente los cambios en la base de datos.

En este momento tenemos dos reglas que estamos tratando de seguir:

Primero, ese viejo código (sql, procs almacenados, función, etc.) funciona como está y debería mantenerse tal cual, sin modificar demasiado a menos que exista el caso (error o cambio de característica), y por supuesto, intente documentarlo tanto como sea posible (especialmente los problemas como: "¡WTF !, ¿por qué hizo eso en vez de eso?").
Segundo, cada nueva característica que ingrese debería usar las mejores prácticas conocidas en este momento y modificar la estructura de la base de datos anterior tan poco como sea posible. Esto introduciría algunas opciones de refactorización de bases de datos, como el uso de vistas editables sobre la estructura anterior, la introducción de nuevas tablas de extensión para las ya existentes, la normalización de la estructura y el suministro de la estructura anterior a través de vistas, etc.

Además, estamos intentando escribir tantas pruebas unitarias como podamos siempre que los analistas comerciales estén trabajando codo a codo y documentando las reglas comerciales.

La refacturación de la base de datos es un campo muy complejo que debe responderse en una breve respuesta. Hay muchos libros que responden a todos sus problemas, uno de ellos es http://databaserefactoring.com/ apuntando en una de las respuestas .

Más tarde Editar: Afortunadamente, la segunda regla también responderá el manejo de los cambios de última hora.