Los datos son la sangre que fluye en cualquier sistema, y gestionar las migraciones de bases de datos con herramientas como Flyway te permite controlar la evolución del esquema relacional de forma segura y versionada. Si trabajas en proyectos grandes, como el del Banco Interamericano de Desarrollo, esta práctica es clave para mantener consistencia entre entornos y evitar caos en la capa de persistencia.
¿Por qué importa controlar la evolución del modelo de datos?
La arquitectura no se reduce al código que escribes en lenguajes imperativos. Debajo de tu lógica de negocio vive un modelo de datos que cambia, crece y muchas veces lo hace a una velocidad distinta a la del dominio.
Cuando ese modelo no se gestiona, aparecen cuellos de botella en rendimiento y en la evolución del sistema completo. Puedes tener una aplicación impecablemente separada en capas y, debajo, un esquema caótico que arrastra todo el proyecto.
¿Qué es una migración de base de datos? Es un cambio versionado al esquema o a los datos, aplicado de forma controlada y reproducible. Cada migración queda registrada para que puedas avanzar o revertir cambios sin perder el historial.
¿Cómo funciona Flyway para gestionar el esquema?
Flyway es una herramienta open source que automatiza la gestión del esquema y de los datos semilla. En el monorepo del proyecto se incluye un módulo dedicado a migraciones, configurado con entornos paralelos a los que ya definiste antes: desarrollo, pruebas y producción.
Al inicializar Flyway, apuntas la herramienta a tu configuración y la base de datos pasa a contener dos cosas: las tablas que ya tenías y una tabla de control que indica en qué estado está el esquema.
¿Qué hace la tabla de control de Flyway?
Esa tabla guarda la historia linealizada de tu base de datos. Te dice cuál fue el baseline, qué versiones se aplicaron después, el origen de cada cambio y datos de auditoría que te permiten ir hacia adelante o hacia atrás cuando lo necesites [02:15].
Cada vez que defines un nuevo archivo SQL con una versión, Flyway lo aplica en orden. En la demo aparecen dos migraciones aplicadas una tras otra, y al revisar la base de datos local ya están la tabla nueva y los datos semilla cargados [02:45].
¿Modelo de dominio igual a modelo de datos?
No necesariamente. Tu modelo de dominio, el que vive en el código y representa las reglas de negocio, puede evolucionar a una velocidad distinta al modelo de datos que persistes. Confundirlos es una trampa común.
Entender bien la arquitectura de datos debajo de tu lógica te ayuda a tomar decisiones sobre cuándo desacoplar, cuándo escalar y cuándo cambiar de tecnología. No todas las bases tienen que ser relacionales: puedes usar bases orientadas a documentos o sin esquema, y aun así llevar control de su evolución.
¿Qué alternativas existen para controlar cambios en bases de datos? Migraciones manuales, migraciones embebidas en frameworks de la lógica de negocio, o migraciones como parte del pipeline de construcción. La última es la más recomendable porque automatiza y versiona todo el flujo.
¿Cómo separar cargas transaccionales y analíticas?
Las cargas OLTP (online transaction processing) manejan transacciones pequeñas y constantes. Las cargas OLAP (online analytical processing) agregan grandes volúmenes de datos para reportes. Mezclarlas en la misma capa es una receta para problemas de rendimiento [04:30].
Para separarlas existen varias técnicas que conviene conocer:
- ETL: extracción, transformación y carga.
- ELT: extracción, carga y transformación.
- Data mesh: enfoque descentralizado de propiedad de datos por dominio.
- Data fabric: capa unificada de acceso e integración.
Cada una resuelve un problema distinto. La elección depende del tamaño del sistema y de cómo se consumen los datos.
¿Cuándo aplicar data mesh o data fabric?
Cuando el problema lo amerita. En sistemas pequeños, una arquitectura ETL clásica suele ser suficiente. En proyectos del tamaño del que plantea el Banco Interamericano de Desarrollo, donde varios dominios producen y consumen datos, data mesh y data fabric ganan sentido.
Piensa en un entrenador de natación que lleva un registro meticuloso: tiempos, distancias, temperatura del agua, equipamiento. Esa misma disciplina aplicas a tus datos cuando los tratas como un activo crítico, no como un efecto secundario del código.
En el siguiente módulo entramos a cómo distribuir un sistema siguiendo un estilo orientado a microservicios, una arquitectura especialmente atractiva para problemas de esta escala. ¿Cómo gestionas hoy las migraciones en tu proyecto? Cuéntalo en los comentarios.
