Control de versiones de base de datos para MySQL

¿Qué método utilizas para controlar la versión de tu base de datos? He confiado todas nuestras tablas de bases de datos como scripts .sql separados en nuestro repository (mercurial). De esa manera, si algún miembro del equipo realiza un cambio en la tabla de empleados, por ejemplo, sabré inmediatamente qué tabla en particular se modificó cuando actualicé mi repository.

Tal método se describió en: ¿Cuáles son las mejores prácticas para los scripts de base de datos bajo control de código ? Actualmente, estoy escribiendo un script de Python para ejecutar todos los archivos .sql dentro de la carpeta de la base de datos, sin embargo, el problema de las dependencias debido a restricciones de clave externa garantiza que no podamos ejecutar los archivos .sql en cualquier orden.

La secuencia de comandos de Python es generar un archivo con el orden en que se ejecutarán los archivos .sql. Ejecutará los archivos .sql en el orden en que aparecen en el archivo tableorder.txt. No se puede ejecutar una tabla hasta que se haya ejecutado su tabla de clave externa, por ejemplo:

tableorder.txt

table3.sql
table1.sql
table7.sql y así sucesivamente

Ya he generado la lista de dependencias para cada tabla, a partir del código, analizando el resultado del comando mysql “mostrar crear tabla”. La lista de dependencias puede verse así:

tblstate: tblcountry //tblcountry.sql must be executed before tblstate.sql etc tblemployee: tbldepartment, tblcountry 

Para generar el contenido del tableorder.txt, necesitaré un algoritmo que se verá así:

 function print_table(table): foreach table in database: if table.dependencies.count == 0 print to tableorder.txt if table.dependencies.count > 0 print_table(dependency) //print dependency first end function 

Como podrás imaginar, esto implica mucha recursión. Estoy empezando a preguntarme si vale la pena el esfuerzo. Si hay alguna herramienta por ahí? ¿Qué herramienta (o algoritmo) existe para generar una lista del orden para ejecutar tablas y vistas .sql separadas teniendo en cuenta las dependencias? ¿Es mejor controlar la versión del archivo .sql separado para cada tabla / vista o mejor controlar la versión de la base de datos completa en un solo archivo .sql? Apreciaré cualquier respuesta ya que esto ha tardado tantos días. Gracias.

No uso MySQL, sino SQL Server, sin embargo, esta es la forma en que versiono mi base de datos:

(Esto es largo, pero al final espero que el razonamiento para que abandone un simple volcado de esquema como la principal forma de manejar el control de versiones de la base de datos se haga evidente).

  1. Realizo una modificación al esquema y lo aplico a una base de datos de prueba .

  2. Generé scripts de cambio delta y un volcado del esquema después de dichos scripts. (Yo uso ApexSQL, pero es probable que haya herramientas específicas de MySQL para ayudar).

    1. Los scripts de cambio delta saben cómo pasar de la versión actual al esquema de destino: ALTER TABLE existente, CREATE TABLE new, DROP VIEW old … Pueden ocurrir múltiples operaciones dentro del mismo archivo .SQL, ya que el delta es importante.

    2. El volcado del esquema es de la versión del esquema de destino: CREATE TABLE a, CREATE VIEW b .. aquí no hay “ALTER” o “DROP”, porque es solo una instantánea del esquema de destino. Hay un archivo .SQL por objeto de base de datos ya que el esquema es importante.

  3. Yo uso RoundhousE para aplicar los scripts de cambio delta. (No uso la función RoundhousE “script en cualquier momento” ya que esto no maneja correctamente las relaciones).

Aprendí de la manera más difícil que la aplicación de los cambios en el esquema de la base de datos no se puede hacer de manera confiable sin un plan integral paso a paso y, de manera similar (como se señala en la pregunta), el orden de las relaciones de las relaciones es importante . El simple almacenamiento del esquema “actual” o “final” no es suficiente. Hay muchos cambios que no se pueden aplicar retroactivamente A-> C sin conocer A-> B-> C y algunos cambios B pueden implicar la lógica de migración o correcciones. Los scripts de cambio de esquema de SQL pueden capturar estos cambios y permitir que se “reproduzcan”.

Sin embargo, al mismo tiempo, solo guardar los scripts delta no proporciona una “vista simple” del esquema de destino . Esta es la razón por la que también vuelco todo el esquema, así como los scripts de cambio y la versión de ambos . El volcado de vista podría, en teoría, usarse para construir la base de datos, pero debido a las dependencias de las relaciones (el tipo que se menciona en la pregunta), puede requerir cierto trabajo y no lo uso como parte de un enfoque automatizado de restauración de esquema: sin embargo, mantener la parte del volcado de esquema del control de versión Hg permite una rápida identificación de los cambios y la visualización del esquema de destino en una versión particular.

Los deltas de cambio avanzan a través de las revisiones mientras que el volcado de esquema proporciona una vista en la revisión actual. Debido a que los cambios de deltas son incrementales y solo hacia adelante , es importante mantener la twig que se ocupa de estos cambios “limpia”, lo que es fácil de hacer con Hg.

En uno de mis proyectos, actualmente estoy en la base de datos número 70, ¡feliz y productivo! – Después de cambiar a esta configuración. (¡Y estos son cambios implementados , no solo cambios de desarrollo!)

Feliz codificacion

No estoy seguro de qué tan bien esto responde a su pregunta, pero tiendo a usar mysqldump (parte de la instalación estándar). Esto me da el sql para crear las tablas y rellenarlas, efectivamente serializando la base de datos. Ejemplo:

 > mysqldump -u username -p yourdatabase > database_dump.sql 

Para cargar una base de datos desde un archivo dump sql:

mysql -u username -p -e “source /path/to/database_dump.sql”

Para responder aún más a su pregunta, yo controlaría la versión de cada tabla por separado solo si hay varias personas trabajando en la base de datos de tal manera que es probable que ocurran conflictos con un solo volcado controlado por una versión. Nunca he llegado a un proyecto en el que este sea el caso (la base de datos tiende a ser una de las partes menos volátiles del sistema después de las fases iniciales del proyecto), por lo que solo controlo el volcado de la base de datos en su totalidad en lugar de cada una. Mesa individual.

Puedes usar sqitch . Aquí hay un tutorial para MySql , pero en realidad es una base de datos independiente.

Los cambios se implementan como scripts nativos de su motor de base de datos seleccionado … Los cambios en la base de datos pueden declarar dependencias en otros cambios, incluso en cambios de otros proyectos de Sqitch. Esto garantiza el orden de ejecución correcto, incluso cuando haya realizado cambios en su VCS fuera de orden … La implementación de cambios se administra manteniendo un archivo de plan. Como tal, no hay necesidad de numerar sus cambios, aunque puede hacerlo si lo desea. A Sqitch no le importa mucho cómo nombra sus cambios … Hasta que etiqueta y libera su aplicación, puede modificar sus scripts de implementación de cambios con la frecuencia que desee. No están encerrados solo porque se han comprometido con su VCS. Esto le permite adoptar un enfoque iterativo para desarrollar el esquema de su base de datos. O, mejor, puede hacer el desarrollo de base de datos de prueba.