Mecanismos para el seguimiento de los cambios en el esquema de BD [cerrado]

Usamos algo similar a bcwoord para mantener nuestros esquemas de base de datos sincronizados en 5 instalaciones diferentes (producción, puesta en escena y algunas instalaciones de desarrollo), y respaldados en control de versiones, y funciona bastante bien. Voy a elaborar un poco:

Para sincronizar la estructura de la base de datos, tenemos un solo script, update.php, y un número 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. El N. los archivos sql se elaboran 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 un nuevo y luego soltar la columna, insertar filas de datos "maestras" como tipos de usuario, etc. Básicamente, puede hacer cualquier cosa, y con scripts de migración de datos adecuados nunca perderá datos.

El script de actualización funciona así:

• Conéctese a la base de datos.
• Hacer una copia de seguridad de la base de datos actual (porque las cosas saldrán mal) [mysqldump].
• Cree una tabla de contabilidad (llamada _meta) si no existe.
• Lea la VERSIÓN actual de la tabla _meta. Asumir 0 si no se encuentra.
• Para todos .archivos sql numerados por encima de la VERSIÓN, ejecutarlos en orden
• Si uno de los archivos produjo un error: vuelva a la copia de seguridad
• De lo contrario, actualice la versión en la tabla de contabilidad a la más alta .archivo sql 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 sola ejecución de script (llamando a update.php con la contraseña de base de datos adecuada, etc.). SVN actualiza los entornos de producción y ensayo a través de un script que llama automáticamente al script de actualización de base de datos, por lo que una actualización de código viene con las actualizaciones de base de datos necesarias.

También podemos usar el mismo script para recrear toda la base de datos desde cero; simplemente soltamos y vuelva a crear la base de datos, luego ejecute el script que repoblará completamente la base de datos. También podemos usar el script para rellenar una base de datos vacía para realizar 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 manualmente las modificaciones en todos base.

Tenga cuidado al pegar consultas de phpMyAdmin sin embargo! Esas consultas generadas generalmente incluyen el nombre de la base de datos, que definitivamente no desea, ya que romperá sus scripts! Algo así como CREAR TABLA mydb.newtable(...) fallará si la base de datos del sistema no se llama mydb. Hemos creado un gancho SVN pre-comentario que no permitirá .archivos sql que contienen la cadena mydb, que es una señal segura de que alguien copió / pegó desde phpMyAdmin sin comprobación.

Mi equipo realiza scripts de todos los cambios en la base de datos, y confirma 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 ir de una versión a la siguiente, solo necesita ejecutar el conjunto de scripts de cambio, y su base de datos está actualizada, y todavía tiene todos sus datos. Puede que no sea el método más fácil, pero definitivamente es efectivo.

El problema aquí es realmente hacer que sea fácil para los desarrolladores escribir sus propios cambios locales en el control de código fuente para compartir con el equipo. He enfrentado este problema durante muchos años, y me inspiré en la funcionalidad de Visual Studio para profesionales de bases de datos. Si quieres una herramienta de código abierto con las mismas características, prueba esto: http://dbsourcetools.codeplex.com / Diviértanse, - Nathan.

Si todavía está buscando soluciones : le proponemos una herramienta llamada neXtep designer. Es un entorno de desarrollo de bases de datos con el que puede poner toda su base de datos bajo control de versiones. Usted trabaja en un repositorio controlado por versiones donde cada cambio puede ser rastreado.

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

Entonces tiene muchas opciones : puede tomar esos scripts y ponerlos en su SVN con el código de su aplicación para que sea implementado por su mecanismo existente. Otra opción es utilizar el mecanismo de entrega de neXtep: los scripts se exportan en algo llamado "delivery package" (scripts SQL + descriptor XML), y un instalador puede entender este paquete e implementarlo en un servidor de destino mientras garantiza la consistencia strcutural, la comprobación de dependencias, el registro instalado versión, 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 de 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 código fuente. A continuación, un simple diff le mostrará lo que cambió.

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

Hemos estado haciendo esto por un tiempo y parece que funciona. Escribimos código para generar el nombre básico de la columna y el tipo de datos se comprueba en un conjunto de pruebas unitarias. Podemos volver a ejecutar esas pruebas en cualquier momento para verificar que la base de datos en el SVN checkout coincide con la base de datos en vivo que la aplicación está realmente ejecutando.

Resulta que, a veces, los desarrolladores también modifican su base de datos sandbox y descuidan actualizar el archivo de esquema en SVN. El código depende entonces de un cambio en la base de datos que no se haya registrado. Ese tipo de error puede ser increíblemente difícil de precisar, pero el conjunto de pruebas lo detectará de inmediato. Esto es particularmente es bueno si lo tienes integrado en un plan de Integración Continua más grande.

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

Luego, confirme el script en el 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 comprobar junto con el código que requiere el cambio de esquema. A continuación, las diferencias en el script indicarán las 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 OR muy útil, pero que también genera script sql para recrear su esquema y\or data. Estos scripts se pueden poner en control de código fuente.

Http://subsonicproject.com/

K. Scott Allen tiene un artículo decente o dos sobre el control de versiones de esquemas, que utiliza el concepto de migración / 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 .

He utilizado la siguiente estructura de proyectos de base de datos en Visual Studio para varios proyectos y ha funcionado bastante bien:

Base de datos

Cambiar Scripts

0.PreDeploy.sql

1.El esquema cambia.sql

2.Cambios de datos.sql

3.Permiso.sql

Crear scripts

Sprocs

Funciones

Vistas

Nuestra construcción luego, el sistema actualiza la base de datos de una versión a la siguiente ejecutando los scripts en el siguiente orden:

1.PreDeploy.sql

2.El esquema cambia.sql

Contenido de la carpeta Crear scripts

2.Cambios de datos.sql

3.Permiso.sql

Cada desarrollador comprueba en sus cambios para un error/característica particular mediante la adición de 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, el contenido de la .se eliminan los archivos sql de la carpeta Change Scripts.

Utilizamos una solución muy simple pero eficaz.

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

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

Así que en nuestro software tenemos algo como esto:

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

Este código comprobará 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 los metadatos.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 los metadatos.sql, pero esto no es un problema importante porque es fácil de probar en la compilación proceso y también lo único que podría suceder es hacer una nueva instalación con una base de datos obsoleta y actualizarla en el primer uso.

Tampoco soportamos degradaciones, pero es por diseño, si algo se rompe en una actualización, restauramos la versión anterior y arreglamos la actualización antes de intentarlo de nuevo.

Creo carpetas con el nombre de las versiones de compilación y pongo 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 le llama con un problema con la versión 1.0.1 y está utilizando 1.0.2, traer la base de datos a su versión no será un problema.

En su base de datos, cree una tabla llamado "esquema" donde se pone en la versión actual de la base de datos. A continuación, escribir un programa que puede actualizar o degradar su base de datos para usted es fácil.

Como dijo Joey, si estás en un mundo de 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 ficheros titulados "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.

Entonces tenemos un script llamado "Migration_watcher" que, como estamos en pre-alfa, actualmente se ejecuta en cada carga de página y comprueba si hay un nuevo archivo migration_XX. sql donde XX es mayor que la versión de migración actual. Si es así, ejecuta todos los archivos migration_XX. sql hasta el mayor número contra la base de datos y listo! los cambios de esquema se automatizan.

Si requiere la capacidad de revertir el sistema requeriría una gran cantidad de ajustes, pero es simple y ha estado funcionando muy bien para nuestro equipo bastante pequeño hasta ahora.

Recomendaría usar Ant (multiplataforma) para el lado de "scripting" (ya que prácticamente puede hablar con cualquier base de datos a través de jdbc) y Subversion para el repositorio de código fuente. Ant le indicará que "haga una copia de seguridad" de su base de datos en archivos locales, antes de realizar cambios. 1. copia de seguridad del esquema de base de datos existente en el archivo a través de Ant 2. control de versiones al repositorio Subversion a través de Ant 3. enviar nuevas sentencias sql a la base de datos a través de Ant

Toad para MySQL tiene una función llamada schema compare que le 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 hacer una nueva instalación de una versión dada puede tardar una eternidad si tiene cientos de tablas y un largo historial de cambios (como nosotros).

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

Me gusta cómo Yii maneja las migraciones de bases de datos. Una migración es básicamente un script PHP implementando CDbMigration. CDbMigration define un método up que contiene la lógica de migración. También es posible implementar un método down para apoyar la reversión de la migración. Alternativamente, safeUp o safeDown se pueden usar para asegurarse de que la migración se realiza 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 invertir, ya sea una por una o en un lote. Crear una migración resulta en código para una clase PHP implementando CDbMigration, con un nombre único 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 obtener más información, consulte el artículo Database Migration del manual.

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

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

Existe una herramienta de línea de comandos mysql-diff que compara esquemas de bases de datos, donde schema 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.