Historia del tema
Trabajar en proyectos grandes requiere que la estructura de la base de datos se desarrolle en paralelo con el código de la aplicación. Sin control de versiones de los cambios en el esquema (adiciones, eliminaciones y modificaciones de tablas, índices, claves), el equipo rápidamente pierde la sincronización, aumenta el riesgo de pérdida de cambios, fallos en las migraciones y se complica la reversión o recreación de errores.
Problema
El enfoque tradicional —la modificación manual de la base de datos a través de scripts SQL— conduce a un orden de ejecución de cambios implícito, complicaciones en la reversión y desincronización de versiones entre entornos (desarrollo, prueba, producción). Sin una herramienta común para almacenar migraciones, es difícil entender quién, cuándo y por qué cambió el esquema.
Solución
Para esta tarea se utilizan sistemas de migración de esquemas y prácticas de versionado de bases de datos. La aplicación de herramientas (por ejemplo, Liquibase, Flyway, Alembic para diferentes SGBD) permite almacenar los scripts SQL de cambios de esquema directamente en el sistema de control de versiones (git), formando una secuencia estricta de migraciones y automatizando las actualizaciones de esquema en todos los entornos.
Ejemplo de código (migración a través de Flyway):
-- V002__add_column_email.sql ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;
Integración de Flyway (por ejemplo, para Java):
Flyway.configure().dataSource(url, user, pass).load().migrate();
Características clave:
¿Se puede almacenar el "estado inicial" del esquema (snapshot) en lugar de migraciones? A primera vista, un "dump" de todo el esquema es más simple que las migraciones. Pero entonces surgirían problemas con la reversión, restauración de estados intermedios y fusión de cambios de diferentes ramas. Las migraciones permiten aplicar solo nuevos cambios de manera secuencial y en el orden correcto.
¿Es necesario sincronizar las migraciones manualmente entre diferentes entornos? No, los sistemas modernos respetan el versionado y aplican automáticamente solo aquellas migraciones que aún no están en la base. Lo principal no es la sincronización manual, sino la aplicación automatizada de migraciones en el despliegue.
¿Es suficiente solo con scripts SQL de migración o debería almacenarse algo más? Una buena práctica es almacenar además de los scripts SQL su descripción (propósito, autor, fecha), así como pruebas validadoras para nuevos cambios estructurales, para automatizar el control de calidad de las migraciones.
El proyecto utilizó dumps comunes del esquema y aplicación "manual" de cambios por los desarrolladores. Después de lanzar la actualización, el cliente notó que algunas de las nuevas columnas no aparecieron en la base en producción, y algunos índices se duplicaban después de cada intento de actualizar el esquema.
Pros:
Rápido para proyectos muy pequeños.
Contras:
Dificultades con el soporte; no se puede entender qué exactamente se cambió y por quién; imposibilidad de revertir; diferentes entornos se desincronizan.
El equipo integró Flyway, todos los cambios estructurales se realizan a través de migraciones con revisión de código, revertir cualquier versión tomó minutos, y es fácil realizar pruebas y controles en todos los entornos.
Pros:
Automatización, historia, baja probabilidad de errores en el despliegue.
Contras:
Necesidad de documentar cada cambio en la estructura un poco más.