Al mismo tiempo que Git se hizo popular, la tendencia de escribir aplicaciones basadas en la web utilizando bibliotecas de mapeo relacional de objetos (libraries) también se hizo bien conocida. La idea clave era la siguiente: dado que los desarrolladores pueden hacer cambios en el código que son fáciles de revertir usando Git, ¿por qué los desarrolladores no pueden hacer lo mismo cuando se trata de cambios de esquema? Después de todo, cualquier nueva característica razonable implica cambios de código y esquema. Los frameworks tan populares como Rails y Django agregaron migration y migración de bases de datos (también conocida como migración de esquemas) como parte de sus ofertas. Pero la migración de bases de datos como concepto no se limita a los marcos web populares. Incluso hay bibliotecas de software de migración de bases de datos independientes como Flyway y Liquibase. ¿Te imaginas poder revertir cambios granulares en el esquema a medida que escribes tu código? Con demasiada frecuencia, encuentro que los artículos sobre migración de bases de datos no discuten lo que significa hacer una de forma activa, como desarrollador. Quiero corregir eso aquí. Con eso en mente, hoy les daré una visión general de lo que implica la migración de bases de datos y cómo hacerlo en un entorno de desarrollo activo. Voy a dividir esto en tres secciones, que cubren lo que sucede durante el proceso de migración, las herramientas comunes utilizadas y los escollos que pueden surgir durante la migración de la base de datos. Esto debería dar a un desarrollador principiante las herramientas para aprender rápidamente las ideas clave detrás de la migración de datos y también aprender los peligros potenciales que debe evitar al usar la migración de bases de datos como parte de su caja de herramientas de desarrollo.
¿Qué Sucede Durante La Migración De La Base De Datos?
Ahora que sabe cómo se produjeron las migraciones de bases de datos, déjeme explicarle lo que realmente implican.
Los cambios granulares Se Generan como Archivos con scripts Individuales
Mencioné cómo las migraciones de bases de datos básicamente rastrean los cambios granulares en su esquema de base de datos (y a veces también en sus datos). Estos cambios granulares se reflejan típicamente como archivos de scripts separados. De esta manera, los cambios de esquema granulares se reflejan como código que se puede capturar con cualquier software de control de versiones. Este es un ejemplo de un archivo de migración en Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
No solo puede tener migraciones como archivos independientes, sino que también puede tener el esquema de base de datos actual como su propio archivo. Normalmente, esto se conoce como archivo de esquema.
Los scripts de migración de bases de datos Dependen de herramientas
Recuperar el script de migración de bases de datos en Ruby de nuestro ejemplo anterior. Aquí hay otro archivo de migración de base de datos del control de código fuente independiente para el software de base de datos Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
Esta vez, el archivo está en formato XML. De hecho, Liquibase puede producir cambios de migración (o conjuntos de cambios, como les gusta llamarlos) en múltiples formatos, como XML y JSON. Por lo tanto, a menos que desee escribir a mano la migración de su base de datos en formato SQL, no hay estándares reales en la forma en que se crean los archivos de migración. Por supuesto, puede escribir sus propios scripts de migración de base de datos personalizados en los archivos SQL. Pero, ¿por qué escribir a mano e introducir errores accidentalmente cuando puede hacer uso de herramientas para generar automáticamente las migraciones de la base de datos?
¿Cómo Se Realiza una Migración de Base de Datos?
Ahora sabe lo que es una migración de base de datos. También necesita saber (al menos conceptualmente) cómo realizar una migración de base de datos. Desafortunadamente, no hay estándares para los archivos de migración de bases de datos, lo que significa que no podemos entrar en demasiados detalles sobre cómo crearlos. En otras palabras, la forma de realizar una migración de base de datos depende en gran medida de la herramienta específica que utilice para la tarea. En esta sección, cubriré las dos formas más comunes de realizar una migración de base de datos.
Opción 1: Utilice un Framework / Biblioteca Dependiente del Lenguaje
Si utiliza un lenguaje popular (Ruby, PHP,Python, etc.) o marco (Rails, Django, etc.), luego hay bibliotecas bien documentadas para la migración de datos dentro del universo del marco/lenguaje elegido. Los marcos web populares vendrán naturalmente con las funciones de migración de bases de datos. Dependiendo de la configuración, incluso puede intercambiar la migración de la base de datos nativa por otras bibliotecas dentro del idioma elegido. Normalmente, en este escenario, se generan los archivos de migración mediante la línea de comandos. Ocasionalmente, es posible que deba escribir a mano el código personalizado para algunos cambios, como la migración de datos o incluso cómo revertir el cambio en sí. Aparte de eso, la biblioteca elegida dentro del marco/lenguaje se encarga de esto por ti.
Opción 2: Utilice Software Independiente centrado en la Migración de bases de datos
En algunos casos, querrá usar software como Flyway o Liquibase que solo actúe como control de código fuente para su base de datos. Al hacer esto, evita estar encerrado en un marco o lenguaje en particular. Esto no significa que tenga cero encierro. Tomemos, por ejemplo, Flyway, que funciona bien con varias bases de datos como Oracle, MySQL y MariaDB. Si no utiliza la migración basada en Java de Flyway (que lo bloquea en Java y Flyway), puede terminar utilizando la migración basada en SQL (que lo bloquea en la base de datos y la ruta de acceso que elija). La buena noticia es que Flyway y Liquibase son relativamente fáciles de usar. También proporcionan una forma de línea de comandos para generar las migraciones y permiten la codificación personalizada para capturar las migraciones de esquemas de base de datos.
Elegir la Mejor opción para Ti
Aquí está mi opinión sobre elegir entre cualquiera de las opciones. Tiendo a ver que la mayoría de los desarrolladores eligen la opción 1. Por lo general, esto se debe a que los desarrolladores ya tienen un lenguaje/marco de trabajo preferido, por lo que cognitivamente hablando, no parece que estén aprendiendo (todavía) otra pieza de software. Y el bloqueo (en el caso de la opción 1, esto sería para el marco y el lenguaje) es totalmente voluntario y deseado. Puedes defender la opción 2 si tu equipo no se ha comprometido completamente con un lenguaje o marco en particular. Sea lo que sea, evite cambiar su elección innecesariamente a mitad del desarrollo. La migración de bases de datos no es un área en la que cambiar las herramientas le brinde enormes beneficios. La mayoría de los beneficios provienen de simplemente tener la migración de bases de datos configurada en primer lugar.
Los peligros de la migración de bases de datos y Cómo Evitarlos
En la sección anterior, cubrí los dos tipos principales de herramientas para la migración de bases de datos: software independiente y dependiente del marco de trabajo/lenguaje. Ambos tipos son fáciles de usar. Ahora, recomendaré tres prácticas recomendadas cuando se trata de realizar una migración de base de datos. Estos consejos abordan el principal peligro de la migración de bases de datos: debe evitar realizar cambios irreversibles.
Elija Una Herramienta de Migración de base de datos y Apéguese a Ella
Mencioné esto brevemente antes, pero vale la pena enfatizar: Quiero advertir contra hacer cambios innecesarios en el conjunto de herramientas simplemente porque es genial. Recuerde que los scripts de migración de bases de datos dependen de la herramienta que utilice para generarlos. No hay estándares adecuados para estos guiones. Si realmente lo desea, incluso puede escribir sus propias instrucciones en SQL. Esto introduce su propio conjunto de problemas; por ejemplo, es probable que los scripts SQL puedan depender de la base de datos. Es posible que las consultas MySQL no funcionen en PostgreSQL y viceversa. Por lo tanto, o está bloqueado en su herramienta de migración de bases de datos, o está bloqueado en la base de datos que elija, o en algunos casos, incluso en ambas. No hay beneficios obvios al cambiar su conjunto de herramientas a menudo, por lo que mi sugerencia es elegir una herramienta de migración de base de datos y atenerse a ella. Hay mejores cosas que hacer con su tiempo que girar sus ruedas innecesariamente.
Eliminar filas o columnas Solo Cuando Esté Absolutamente Seguro De Que Necesita
Cuando se trata de migraciones, en su mayor parte, puede revertirlas cuando lo necesite. Las herramientas típicas de migración de bases de datos pueden manejar cambios reversibles simples. E incluso cuando no pueden, puede agregar fácilmente su propio código personalizado para ayudarlo a revertir. Por ejemplo, en Rails, simplemente agrega el código en reversible.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
Los cambios más difíciles de revertir tienden a implicar la eliminación de cosas: específicamente, eliminar columnas o filas de datos. Si su base de datos contiene muchos datos, es posible que tenga que escribir una cantidad significativa de código personalizado para intentar revertir los cambios. Por lo tanto, si está considerando eliminar datos de su base de datos, tenga mucho cuidado. Esos tipos de cambios son difíciles de deshacer. Otros cambios difíciles de revertir incluyen cambiar el nombre de las columnas y cambiar el tipo de datos de una columna que ya contiene datos. Una regla general con la que me gusta ir es esta: casi nunca debes eliminar columnas hasta la siguiente mayor (conoces a semver, ¿verdad?) lanzar. Esta regla se aplica incluso si tengo columnas que quiero dejar de usar. En lugar de eliminar columnas, anunciaré en las versiones menores qué columnas quedarán obsoletas en el futuro. Cuando llegue el momento de una versión importante, eliminaré esas columnas por completo. De esa manera, reduzco las posibilidades de realizar un cambio accidental y no deseado que será un proceso horrible de revertir a mano.
Implementar indicadores de características
Otra excelente estrategia para la migración de bases de datos es implementar indicadores de características, especialmente cuando tiene un equipo grande y varias personas están tratando de implementar diferentes características para la misma base de código. Según Martin Fowler, las banderas de características son » una técnica poderosa, que permite a los equipos modificar el comportamiento del sistema sin cambiar el código.»De hecho, cuanto más grande sea tu equipo y más complejo sea tu código base, más banderas de características brillarán. Los indicadores de características ayudan a mitigar el riesgo cuando se trata de migraciones de bases de datos. Tratar de desenredar los cambios cuando necesita revertir ciertas características puede ser una verdadera pesadilla. Los indicadores de características funcionan igual de bien si desea realizar cambios pequeños o grandes en el esquema de la base de datos. Al usar indicadores de características, le recomiendo que apunte a cambios más frecuentes y granulares en general. Y realmente puede ver cómo los indicadores de características ayudan a su proceso de desarrollo cuando realiza un cambio masivo de esquema. Por favor, sigue intentando dividir este enorme cambio de esquema en trozos más pequeños y finos. No necesitas impresionar a nadie con lo mucho que puedes meter en un cambio. Es mejor agregar salvaguardas a sus prácticas de desarrollo implementando las tres recomendaciones de las que he hablado en esta sección.
Conclusión
Los desarrolladores necesitan todas las herramientas que puedan obtener para hacer sus vidas más fáciles. La migración de bases de datos es una de esas herramientas imprescindibles para la caja de herramientas del desarrollador. En el futuro, preveo que el empleo de migraciones de bases de datos evolucionará de una mejor práctica de desarrollo a una práctica estándar de desarrollo. La gente te mirará raro por no usar la migración de bases de datos en absoluto. Sin embargo, es importante tener en cuenta cómo las migraciones de bases de datos pueden resultar contraproducentes, en particular para los cambios de esquema difíciles de revertir. Esté absolutamente seguro de esos cambios antes de hacerlos funcionar. Si aún no está utilizando la migración de bases de datos en su proceso, ¿qué está esperando? Es fácil de comenzar, e incluso puede agregarlo a mitad de su ciclo de desarrollo. Estarás agradecido de haberlo hecho. Porque cuando llegue el día en que necesite revertir sus cambios y los cambios involucren la base de datos, deseará tener algo que lo ayude a hacerlo en cuestión de segundos. La migración de bases de datos es algo que desearás tener.