migración de esquema

Estos son los pasos generales de la escritura dual (también llamada escritura doble): ^{[ 1 ]}

1. Prepare el esquema para que pueda almacenar datos tanto en el formato antiguo como en el nuevo. Esto podría implicar añadir una nueva versión de una columna o una tabla, sin afectar a los datos existentes.
2. Implemente una nueva versión de la aplicación que escriba datos tanto en el formato antiguo como en el nuevo (de ahí el nombre de escritura dual). Es importante garantizar la coherencia de estas escrituras. A partir de este momento, todos los datos recién escritos existirán en ambos formatos.
3. Realiza una copia de seguridad en la base de datos: copia los datos del formato antiguo al nuevo formato que existía previamente y que no se ha actualizado recientemente, por lo que aún no se ha duplicado. Después de esto, la base de datos tendrá una réplica completa de los datos en ambos formatos.
4. Implemente una nueva versión de la aplicación que cambie la lectura de datos al nuevo formato y detenga la escritura dual. En sistemas distribuidos , es importante cambiar la ruta de lectura antes de detener la escritura dual, por lo que este paso puede dividirse en dos.
5. Elimine los datos del formato antiguo del esquema.

La lectura dual (también llamada doble lectura) es similar a la escritura dual, con los siguientes pasos: ^{[ 2 ]}

1. Prepare el esquema para que pueda almacenar datos tanto en el formato antiguo como en el nuevo. Igual que lo anterior.
2. Implementa una nueva versión de la aplicación que intente leer tanto el formato antiguo como el nuevo (de ahí el nombre de lectura dual) y que funcione con el formato que esté presente en ese momento.
3. Implemente otra versión de la aplicación que deje de escribir en el formato antiguo y comience a escribir en el nuevo. Todo debería seguir funcionando con normalidad, ya que la lectura dual reconocerá que debe leer el nuevo formato para las filas recién escritas.
4. Realizar una actualización de la base de datos: para todos los datos que se escribieron en el formato antiguo, transferirlos al nuevo formato.
5. Implementa una vez más un cambio en la aplicación que impida la lectura de los datos antiguos.
6. Elimine los datos del formato antiguo del esquema.

En este enfoque combinado, la aplicación se modifica para admitir tanto lectura como escritura dual. Dado que ambas estrategias individuales garantizan que la base de datos permanezca en línea sin interrupciones, el enfoque combinado también logra el mismo resultado. Esta estrategia permite un control más preciso sobre el relleno de la base de datos, que puede dividirse en lotes más pequeños, y se pueden usar indicadores de características para alternar las rutas de lectura y escritura de forma más libre e independiente. Esto también puede ser útil cuando no se puede garantizar la escritura dual regular en transacciones consistentes.

• Todas las estrategias anteriores logran una migración sin tiempo de inactividad.
• La escritura dual tiene la ventaja de que las versiones antigua y nueva de los datos coexisten, lo que permite compararlas para garantizar la coherencia antes de adoptar el nuevo formato. Sin embargo, esto conlleva el inconveniente de duplicar los requisitos de almacenamiento.
• Con la lectura dual, solo existe una versión de cada dato en un momento dado, por lo que no hay un aumento en los requisitos de almacenamiento.
• El enfoque combinado permite realizar el relleno en lotes más pequeños, de modo que se pueda controlar el aumento del almacenamiento, pero esto conlleva una mayor complejidad.

Los equipos de desarrolladores de software suelen utilizar sistemas de control de versiones para gestionar y colaborar en los cambios realizados en las versiones del código fuente. Diferentes desarrolladores pueden trabajar en ramas divergentes, relativamente antiguas o nuevas, del mismo código fuente para realizar cambios y adiciones durante el desarrollo.

Suponiendo que el software en desarrollo interactúe con una base de datos, cada versión del código fuente puede asociarse con al menos un esquema de base de datos con el que sea compatible.

Según las buenas prácticas de pruebas de software , se pueden realizar migraciones de esquema en bases de datos de prueba para garantizar que su esquema sea compatible con el código fuente. Para agilizar este proceso, se suele utilizar una herramienta de migración de esquema como parte de la compilación automatizada del software, como requisito previo para la fase de pruebas automatizadas .

Se puede decir que las herramientas de migración de esquemas resuelven los problemas de versionado de los esquemas de bases de datos, al igual que los sistemas de control de versiones resuelven los problemas de versionado del código fuente. En la práctica, muchas herramientas de migración de esquemas se basan en una representación textual de los cambios de esquema (como archivos que contienen sentencias SQL), de modo que el historial de versiones de los cambios de esquema se puede almacenar junto con el código fuente del programa dentro del sistema de control de versiones. Este enfoque garantiza que la información necesaria para recuperar un esquema de base de datos compatible para una rama de código específica se pueda recuperar del propio árbol de código fuente. Otra ventaja de este enfoque es la gestión de cambios de esquema concurrentes y conflictivos; los desarrolladores pueden simplemente usar sus herramientas habituales de resolución de conflictos basadas en texto para conciliar las diferencias.

Las herramientas de migración de esquemas podrían considerarse una herramienta para rastrear el historial de un esquema en evolución (es decir, la evolución del esquema ).

Los desarrolladores ya no necesitan eliminar toda la base de datos de prueba para crear una nueva desde cero (por ejemplo, utilizando scripts de creación de esquemas de herramientas de generación de DDL). Además, si la generación de datos de prueba consume mucho tiempo, los desarrolladores pueden evitar regenerarlos para cambios pequeños y no destructivos en el esquema.