¿Cómo versiona su esquema de database?

¿Cómo preparas tus deltas SQL? ¿Guardas manualmente cada SQL que cambia el esquema en una carpeta delta, o tienes algún tipo de process de difusión automatizado?

Estoy interesado en las convenciones para el control de versiones del esquema de la database junto con el código fuente. ¿Tal vez un gancho precompromiso que difiera el esquema?

Además, ¿qué opciones existen para los deltas diferentes aparte de DbDeploy ?

EDITAR: al ver las respuestas, me gustaría aclarar que estoy familiarizado con el esquema estándar para ejecutar una migration de database usando deltas. Mi pregunta es acerca de crear los deltas, preferiblemente de forma automática.

Además, el control de versiones es para PHP y MySQL si hace la diferencia. (No hay soluciones Ruby por favor).

Ver

¿Hay un sistema de control de versiones para cambios en la estructura de la database?

¿Cómo puedo versionar mi database MS SQL en SVN?

y el artículo de Jeff

Obtenga su database bajo control de versiones

Siento tu dolor y desearía que hubiera una mejor respuesta. Esto podría estar más cerca de lo que estabas buscando.

Mecanismos para el seguimiento de cambios en el esquema de DB

En general, creo que no hay una solución adecuada y aceptada para esto, y me refiero a esta área.

Puede echar un vistazo a otro hilo similar: ¿cómo puedo versionar mi database MS SQL en SVN? .

Si aún está buscando opciones, eche un vistazo al diseñador de neXtep. Es un entorno de desarrollo de database GPL gratuito basado en los conceptos de control de versiones. En el entorno siempre trabajas con entidades versionadas y puedes enfocarte en el desarrollo del model de datos. Una vez que se realiza un lanzamiento, el motor de generación de SQL conectado al sistema de control de versiones puede generar cualquier delta que necesite entre 2 versiones, y le ofrecerá algún mecanismo de entrega si lo necesita.

Entre otras cosas, puede sincronizar e invertir la synchronization de su database durante desarrollos, crear diagtwigs de models de datos, consultar su database utilizando clientes SQL integrados, etc.

Eche un vistazo a la wiki para más información: http://www.nextep-softwares.com/wiki

Actualmente es compatible con Oracle, MySql y PostgreSql y está en Java, por lo que el producto se ejecuta en Windows, Linux y Mac.

No event handlingltas. Realizo cambios en una database maestra y tengo una herramienta que crea un script de construcción basado en XML basado en la database maestra.

Cuando llega el momento de actualizar una database existente, tengo un progtwig que usa el script de construcción basado en XML para crear una nueva database y las tablas desnudas. Luego copio los datos de la database anterior usando INSERT INTO x SELECT FROM yy luego aplico todos los índices, restricciones y triggers.

Las nuevas tablas, columnas nuevas y columnas eliminadas se manejan automáticamente y con algunos pequeños trucos para ajustar la rutina de copydo puedo manejar los cambios de nombre de columna, tipo de columna y otras refactorizaciones básicas.

No recomendaría esta solución en una database con una gran cantidad de datos, pero actualizo regularmente una database que tiene más de 1 GB con 400 tablas.

No mencionó qué RDBMS está utilizando, pero si se trata de MS SQL Server, la comparación SQL de Red-Gate ha sido indispensable para nosotros en la creación de deltas entre los scripts de creación de objects.

No soy de los que tocan mi propio cuerno, pero he desarrollado una aplicación web interna para seguir los cambios en los esquemas de bases de datos y crear scripts de actualización versionados.

Esta herramienta se llama Brasil y ahora es de código abierto bajo una licencia de MIT. Brasil está basado en ruby ​​/ ruby ​​on rails y admite la implementación de cambios en cualquier database que Ruby DBI admita (MySQL, ODBC, Oracle, Postgres, SQLite).

Se planificó la implementación de los scripts de actualización en el control de versiones.

http://bitbucket.org/idler/mmp – herramienta de control de versiones para mysql, escrita en PHP

Me aseguro de que los cambios de esquema sean siempre aditivos. Así que no quito columnas y tablas, porque eso borrará los datos y no se pueden revertir más tarde. De esta forma, el código que usa la database puede revertirse sin perder datos o funcionalidad.

Tengo un script de migration que contiene instrucciones que crean tablas y columnas, si aún no existen, y las completa con datos.

El script de migration se ejecuta cada vez que se actualiza el código de producción y después de nuevas instalaciones.

Cuando quisiera eliminar algo, lo hago eliminándolo del script de installation de la database y del script de migration para que estos elementos de esquema obsoletos se eliminen gradualmente en las nuevas instalaciones. Con la desventaja de que las nuevas instalaciones no pueden degradarse a una versión anterior antes de la installation.

Y, por supuesto, ejecuto DDL a través de estos scripts y nunca directamente en la database para mantener las cosas sincronizadas.

Estamos exportando los datos a un formatting portátil (usando nuestra cadena de herramientas), y luego importándolos a un nuevo esquema. sin necesidad de delta SQL. Muy recomendable.

Utilizo la database Firebird para la mayoría del desarrollo y utilizo la herramienta de administración FlameRobin para ello. Tiene una buena opción para registrar todos los cambios. Puede registrar todo en un file grande, o un file por cambio de database. Utilizo esta segunda opción, y luego almaceno cada script en el software de control de versiones: antes usaba Subversion, ahora uso Git.

Supongo que puedes encontrar alguna herramienta MySQL que tenga la misma function de logging que FlameRobin para Firebird.

En una de las tablas de la database, guardo el número de versión de la estructura de la database, por lo que puedo actualizar fácilmente cualquier database. También escribí un simple script PHP que ejecuta esos scripts SQL uno por uno en cualquier database de destino (la ruta de la database y el nombre de usuario / contraseña se suministran en la command-line).

También hay una opción para registrar todas las instrucciones DML (insert, actualizar eliminar) y lo activo mientras modifico algunos datos 'pnetworkingeterminados' que contiene cada database.

Escribí un buen libro blanco sobre cómo hago todo esto en detalle. Puede download el documento en formatting .pdf junto con los scripts PHP de demostración desde aquí .

También desarrollé un set de scripts PHP donde los desarrolladores pueden enviar sus scripts deltasql a un repository central.

En una de las tablas de la database (llamada TBSYNCHRONIZE), almaceno el número de versión de la última secuencia de commands ejecutada, de modo que puedo actualizar fácilmente cualquier database usando la interfaz web o un cliente desarrollado a propósito para Eclipse.

La interfaz web permite administrar varios proyectos. También es compatible con "twigs" de bases de datos.

Puede probar la aplicación en http://www.gpu-grid.net/deltasql (si inicia session como administrador con contraseña testdbsync). La aplicación es de código abierto y se puede download aquí: http://sourceforge.net/projects/deltasql

deltasql se usa productivamente en Suiza e India, y es popular en Japón.

Hace algunos meses busqué la herramienta para versionar el esquema de MySQL. Encontré muchas herramientas útiles, como la migration Doctrine, la migration RoR, algunas herramientas escritas en Java y Python.

Pero ninguno de ellos estaba satisfecho con mis requisitos.

Mis requisitos:

  1. Sin requisitos, excluye PHP y MySQL
  2. No hay files de configuration de esquema, como schema.yml en Doctrine
  3. Capaz de leer el esquema actual de la connection y crear un nuevo script de migration, que representa un esquema idéntico en otras instalaciones de la aplicación.

Empecé a escribir mi herramienta de migration, y hoy tengo la versión beta.

Por favor, inténtelo, si tiene interés en este tema. Por favor envíeme futuras requestes y errores.

Código fuente: bitbucket.org/idler/mmp/src Resumen en inglés: bitbucket.org/idler/mmp/wiki/Home Descripción general en ruso: antonoff.info/development/mysql-migration-with-php-project

Estoy interesado en este tema también.

Hay algunas discusiones sobre este tema en la wiki de Django .

Curiosamente, parece que CakePHP tiene versiones de esquema incorporadas usando solo el command cake schema generate .

Para MySQL

Cuando aterrizo en un nuevo DB:

En primer lugar, verifico la estructura:

 mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt cat DIFF_FILENAME.txt | less 

Gracias a los usuarios de stackoverflow pude escribir este guión rápido para encontrar diferencias de estructura.

src: https://stackoverflow.com/a/8718572/4457531 y https://stackoverflow.com/a/26328331/4457531

En un segundo paso, mysqldiff datos, tabla por tabla con mysqldiff . Es un poco arcaico, pero un bucle de php basado en information_schema datas hace que el trabajo sea seguro

Para el control de versiones, uso de la misma manera, pero formatting un script de actualización SQL (para actualizar o retrotraer) con resultados diff y utilizo el convenio de número de versión (con varias modificaciones, el número de versión parece una dirección IP) .

 initial version : 1.0.0 ^ ^ ^ | | | structure change: - | | datas added: -------- | datas updated: -------- 

Estoy usando versiones estrictas del esquema de la database (rastreado en una tabla separada). Los scripts se almacenan en control de versión, pero todos verifican la versión de esquema actual antes de realizar cualquier cambio.

Aquí está la implementación completa para SQL Server (la misma solución podría desarrollarse para MySQL si fuera necesario): Cómo mantener la versión de SQL Server Database Schema

Después de una larga investigación, descubrí que hay algunas herramientas de terceros o types de proyectos de Visual Studio que no me satisfacen, o solo blogs sobre la teoría pero sin implementación. Así que implementé un sistema que funciona, que se usa casi un año y que se explica aquí:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

dependiendo del interés, continuará escribiendo más.