Mecanismos para rastrear cambios en el esquema de base de datos [cerrado]

https://stackoverflow.com/questions/1607

08-06-2019
|

Pregunta

¿Cuáles son los mejores métodos para rastrear y/o automatizar los cambios en el esquema de base de datos?Nuestro equipo utiliza Subversion para el control de versiones y hemos podido automatizar algunas de nuestras tareas de esta manera (enviar compilaciones a un servidor de prueba, implementar código probado en un servidor de producción), pero todavía estamos realizando actualizaciones de la base de datos manualmente.Me gustaría encontrar o crear una solución que nos permita trabajar de manera eficiente en servidores con diferentes entornos mientras sigo usando Subversion como backend a través del cual el código y las actualizaciones de la base de datos se envían a varios servidores.

Muchos paquetes de software populares incluyen scripts de actualización automática que detectan la versión de la base de datos y aplican los cambios necesarios.¿Es esta la mejor manera de hacerlo incluso a mayor escala (en múltiples proyectos y, a veces, en múltiples entornos e idiomas)?Si es así, ¿existe algún código que simplifique el proceso o es mejor implementar nuestra propia solución?¿Alguien ha implementado algo similar antes y lo ha integrado en los ganchos posteriores a la confirmación de Subversion, o es una mala idea?

Si bien sería preferible una solución que admita múltiples plataformas, definitivamente necesitamos admitir la pila Linux/Apache/MySQL/PHP ya que la mayor parte de nuestro trabajo se realiza en esa plataforma.

Solución

En el mundo Rails, existe el concepto de migraciones, scripts en los que los cambios en la base de datos se realizan en Ruby en lugar de una versión SQL específica de la base de datos.Su código de migración de Ruby termina convirtiéndose en el DDL específico de su base de datos actual;esto hace que cambiar de plataforma de base de datos sea muy fácil.

Por cada cambio que realiza en la base de datos, escribe una nueva migración.Las migraciones suelen tener dos métodos:un método "arriba" en el que se aplican los cambios y un método "abajo" en el que se deshacen los cambios.Un solo comando actualiza la base de datos y también se puede utilizar para llevar la base de datos a una versión específica del esquema.En Rails, las migraciones se guardan en su propio directorio en el directorio del proyecto y se registran en el control de versiones como cualquier otro código de proyecto.

Esta guía de Oracle para las migraciones de Rails cubre bastante bien las migraciones.

Los desarrolladores que utilizan otros idiomas han analizado las migraciones y han implementado sus propias versiones específicas del idioma.yo se de alboroto, un sistema de migraciones PHP que sigue el modelo de las migraciones de Rails;puede que sea lo que estás buscando.

Otros consejos

Usamos algo similar a bcwoord para mantener los esquemas de nuestra base de datos sincronizados en 5 instalaciones diferentes (producción, preparación y algunas instalaciones de desarrollo) y respaldados en control de versiones, y funciona bastante bien.Explicaré un poco:

Para sincronizar la estructura de la base de datos disponemos de un único script, update.php, y de una serie de archivos numerados 1.sql, 2.sql, 3.sql, etc.El script utiliza una tabla adicional para almacenar el número de versión actual de la base de datos.Los archivos N.sql están elaborados a mano, para pasar de la versión (N-1) a la versión N de la base de datos.

Se pueden usar para agregar tablas, agregar columnas, migrar datos de un formato de columna antiguo a uno nuevo y luego eliminar la columna, insertar filas de datos "maestros", como tipos de usuarios, etc.Básicamente, puede hacer cualquier cosa y con los scripts de migración de datos adecuados nunca perderá datos.

El script de actualización funciona así:

Conéctese a la base de datos.

Haga una copia de seguridad de la base de datos actual (porque cosas voluntad sale mal) [mysqldump].

Cree una tabla de contabilidad (llamada _meta) si no existe.

Lea la VERSIÓN actual de la _meta tabla.Suponga 0 si no se encuentra.

Para todos los archivos .sql con números superiores a VERSIÓN, ejecútelos en orden

Si uno de los archivos produjo un error:volver a la copia de seguridad

De lo contrario, actualice la versión en la tabla de contabilidad al archivo .sql más alto ejecutado.

Todo entra en el control de código fuente y cada instalación tiene un script para actualizar a la última versión con una única ejecución del script (llamando a update.php con la contraseña adecuada de la base de datos, etc.).Actualizamos SVN los entornos de ensayo y producción a través de un script que llama automáticamente al script de actualización de la base de datos, por lo que una actualización del código viene con las actualizaciones necesarias de la base de datos.

También podemos utilizar el mismo script para recrear toda la base de datos desde cero;simplemente soltamos y volvemos a crear la base de datos, luego ejecutamos el script que repoblará completamente la base de datos.También podemos usar el script para completar una base de datos vacía para pruebas automatizadas.

Solo tomó unas pocas horas configurar este sistema, es conceptualmente simple y todos obtienen el esquema de numeración de versiones, y ha sido invaluable al tener la capacidad de avanzar y evolucionar el diseño de la base de datos, sin tener que comunicarse o ejecutar las modificaciones manualmente. en todas las bases de datos.

¡Sin embargo, tenga cuidado al pegar consultas de phpMyAdmin! Esas consultas generadas generalmente incluyen el nombre de la base de datos, lo cual definitivamente no deseas ya que romperá tus scripts.Algo como CREAR TABLA mydb.newtable(...) fallará si la base de datos del sistema no se llama mydb.Creamos un gancho SVN previo al comentario que no permitirá archivos .sql que contengan el mydb string, lo cual es una señal segura de que alguien copió/pegó desde phpMyAdmin sin la verificación adecuada.

Mi equipo escribe todos los cambios en la base de datos y envía esos scripts a SVN, junto con cada versión de la aplicación.Esto permite cambios incrementales de la base de datos, sin perder ningún dato.

Para pasar de una versión a la siguiente, solo necesita ejecutar el conjunto de scripts de cambio, su base de datos estará actualizada y aún tendrá todos sus datos.Puede que no sea el método más sencillo, pero definitivamente es eficaz.

El problema aquí es realmente facilitar a los desarrolladores la creación de scripts de sus propios cambios locales en el control de código fuente para compartirlos con el equipo.Me he enfrentado a este problema durante muchos años y me inspiré en la funcionalidad de Visual Studio para profesionales de bases de datos.Si desea una herramienta de código abierto con las mismas características, pruebe esto: http://dbsourcetools.codeplex.com/ Diviértete, - Nathan.

Si todavía estás buscando soluciones:Proponemos una herramienta llamada neXtep Designer.Es un entorno de desarrollo de bases de datos con el que puedes poner toda tu base de datos bajo control de versiones.Trabaja en un repositorio controlado por versiones donde se puede rastrear cada cambio.

Cuando necesite publicar una actualización, puede confirmar sus componentes y el producto generará automáticamente el script de actualización de SQL de la versión anterior.Por supuesto, puede generar este SQL desde 2 versiones cualesquiera.

Entonces tienes muchas opciones:puede tomar esos scripts y colocarlos en su SVN con el código de su aplicación para que su mecanismo existente los implemente.Otra opción es utilizar el mecanismo de entrega de neXtep:Los scripts se exportan en algo llamado "paquete de entrega" (scripts SQL + descriptor XML), y un instalador puede entender este paquete e implementarlo en un servidor de destino mientras garantiza la coherencia estructural, la verificación de dependencias, el registro de la versión instalada, etc.

El producto es GPL y está basado en Eclipse por lo que se ejecuta en Linux, Mac y Windows.También es compatible con Oracle, Mysql y Postgresql en este momento (el soporte para DB2 está en camino).Echa un vistazo a la wiki donde encontrarás información más detallada:http://www.nextep-softwares.com/wiki

Vuelque su esquema en un archivo y agréguelo al control de fuente.Luego, una simple diferencia le mostrará qué cambió.

Scott Ambler produce una gran serie de artículos (y es coautor de un libro) sobre la refactorización de bases de datos, con la idea de que esencialmente debes aplicar los principios y prácticas de TDD para mantener tu esquema.Usted configura una serie de pruebas unitarias de estructura y datos semilla para la base de datos.Luego, antes de cambiar algo, modifica/escribe pruebas para reflejar ese cambio.

Hemos estado haciendo esto por un tiempo y parece funcionar.Escribimos código para generar comprobaciones básicas de nombres de columnas y tipos de datos en un conjunto de pruebas unitarias.Podemos volver a ejecutar esas pruebas en cualquier momento para verificar que la base de datos en el proceso de pago SVN coincida con la base de datos en vivo que la aplicación realmente está ejecutando.

Resulta que los desarrolladores a veces también modifican su base de datos sandbox y se olvidan de actualizar el archivo de esquema en SVN.Luego, el código depende de un cambio de base de datos que no se ha registrado.Ese tipo de error puede ser tremendamente difícil de precisar, pero el conjunto de pruebas lo detectará de inmediato.Esto es particularmente bueno si lo tiene integrado en un plan de integración continua más amplio.

K.Scott Allen tiene uno o dos artículos decentes sobre control de versiones de esquemas, que utiliza el concepto de migraciones/scripts de actualización incremental al que se hace referencia en otras respuestas aquí;ver http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx.

Es un poco de baja tecnología y podría haber una solución mejor, pero podría simplemente almacenar su esquema en un script SQL que se puede ejecutar para crear la base de datos.Creo que puedes ejecutar un comando para generar este script, pero desafortunadamente no conozco el comando.

Luego, envíe el script al control de código fuente junto con el código que funciona en él.Cuando necesite cambiar el esquema junto con el código, el script se puede registrar junto con el código que requiere el esquema modificado.Luego, las diferencias en el script indicarán diferencias en los cambios de esquema.

Con este script, podría integrarlo con DBUnit o algún tipo de script de compilación, por lo que parece que podría encajar con sus procesos ya automatizados.

Si está utilizando C#, eche un vistazo a Subsonic, una herramienta ORM muy útil, pero que también genera un script SQL para recrear su esquema y/o datos.Estos scripts luego se pueden poner en control de código fuente.

http://subsonicproject.com/

He utilizado la siguiente estructura de proyecto de base de datos en Visual Studio para varios proyectos y funcionó bastante bien:

Base de datos

Cambiar guiones

0.PreDeploy.sql

1.Cambiosdeesquema.sql

2.CambiosdeDatos.sql

3.Permisos.sql

Crear guiones

Sprocs

Funciones

Puntos de vista

Luego, nuestro sistema de compilación actualiza la base de datos de una versión a la siguiente ejecutando los scripts en el siguiente orden:

1.PreDeploy.sql

2.SchemaChanges.sql

Contenido de la carpeta Crear scripts

2.CambiosdeDatos.sql

3.Permisos.sql

Cada desarrollador verifica sus cambios para detectar un error o característica en particular agregando su código al final de cada archivo.Una vez que una versión principal está completa y ramificada en el control de código fuente, se elimina el contenido de los archivos .sql en la carpeta Change Scripts.

Utilizamos una solución muy simple pero efectiva.

Para instalaciones nuevas, tenemos un archivo metadata.sql en el repositorio que contiene todo el esquema de base de datos, luego, en el proceso de compilación, usamos este archivo para generar la base de datos.

Para las actualizaciones, agregamos las actualizaciones en el software codificado.Lo mantenemos codificado porque no nos gusta resolver problemas antes de que realmente SEAN un problema, y este tipo de cosas no resultó ser un problema hasta ahora.

Entonces en nuestro software tenemos algo como esto:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Este código verificará si la base de datos está en la versión 1 (que se almacena en una tabla creada automáticamente), si está desactualizada, entonces se ejecuta el comando.

Para actualizar metadata.sql en el repositorio, ejecutamos estas actualizaciones localmente y luego extraemos los metadatos completos de la base de datos.

Lo único que sucede de vez en cuando es olvidarse de enviar metadata.sql, pero esto no es un problema importante porque es fácil de probar en el proceso de compilación y además lo único que podría suceder es realizar una nueva instalación con una base de datos obsoleta y la actualicé en el primer uso.

Además, no admitimos degradaciones, pero es por diseño: si algo falla en una actualización, restauramos la versión anterior y reparamos la actualización antes de volver a intentarlo.

Creo carpetas con el nombre de las versiones de compilación y coloco scripts de actualización y degradación allí.Por ejemplo, podría tener las siguientes carpetas:1.0.0, 1.0.1 y 1.0.2.Cada uno contiene el script que le permite actualizar o degradar su base de datos entre versiones.

Si un cliente o cliente lo llama con un problema con la versión 1.0.1 y usted está usando la 1.0.2, devolver la base de datos a su versión no será un problema.

En su base de datos, cree una tabla llamada "esquema" donde ingrese la versión actual de la base de datos.Entonces, escribir un programa que pueda actualizar o degradar su base de datos es fácil.

Tal como dijo Joey, si estás en un mundo Rails, usa Migraciones.:)

Para mi proyecto PHP actual utilizamos la idea de migraciones Rails y tenemos un directorio de migraciones en el que guardamos los archivos con el título "migration_XX.sql", donde XX es el número de la migración.Actualmente estos archivos se crean a mano a medida que se realizan actualizaciones, pero su creación podría modificarse fácilmente.

Luego tenemos un script llamado "Migration_watcher" que, como estamos en pre-alfa, actualmente se ejecuta en cada carga de página y verifica si hay un nuevo archivo migración_XX.sql donde XX es mayor que la versión de migración actual.Si es así, ejecuta todos los archivos migración_XX.sql hasta el número más grande en la base de datos y ¡listo!Los cambios de esquema están automatizados.

Si necesita la capacidad de revertir el sistema, sería necesario realizar muchos ajustes, pero es simple y hasta ahora ha funcionado muy bien para nuestro equipo bastante pequeño.

Recomendaría usar Ant (multiplataforma) para el lado de "scripting" (ya que prácticamente puede comunicarse con cualquier base de datos a través de jdbc) y Subversion para el repositorio de origen.Ant le permitirá "hacer una copia de seguridad" de su base de datos en archivos locales, antes de realizar cambios.1.Copia de seguridad del esquema DB existente para archivar a través de Ant 2.Control de versión al repositorio de subversión a través de Ant 3.enviar nuevas declaraciones SQL a la base de datos a través de Ant

Toad para MySQL tiene una función llamada comparación de esquemas que te permite sincronizar 2 bases de datos.Es la mejor herramienta que he usado hasta ahora.

Las migraciones en mi humilde opinión tienen un gran problema:

Actualizar de una versión a otra funciona bien, pero realizar una instalación nueva de una versión determinada puede llevar una eternidad si tiene cientos de tablas y un largo historial de cambios (como lo tenemos nosotros).

Ejecutar todo el historial de deltas desde la línea base hasta la versión actual (para cientos de bases de datos de clientes) puede llevar mucho tiempo.

Me gusta la forma en que yii maneja las migraciones de bases de datos.Una migración es básicamente un script PHP que implementa CDbMigration. CDbMigration define un up método que contiene la lógica de migración.También es posible implementar un down método para apoyar la reversión de la migración.Alternativamente, safeUp o safeDown se puede utilizar para garantizar que la migración se realice en el contexto de una transacción.

La herramienta de línea de comandos de Yii yiic contiene soporte para crear y ejecutar migraciones.Las migraciones se pueden aplicar o revertir, ya sea una por una o en lote.La creación de una migración da como resultado el código para la implementación de una clase PHP CDbMigration, con un nombre exclusivo basado en una marca de tiempo y un nombre de migración especificado por el usuario.Todas las migraciones que se han aplicado previamente a la base de datos se almacenan en una tabla de migración.

Para más información consulte el Migración de base de datos artículo del manual.

Pruebe db-deploy, principalmente una herramienta Java, pero también funciona con PHP.

Hay una línea de comando diferencia-mysql herramienta que compara esquemas de bases de datos, donde el esquema puede ser una base de datos activa o un script SQL en el disco.Es bueno para la mayoría de las tareas de migración de esquemas.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow