¿Cómo versionas tu esquema de base de datos? [cerrado]

¿Cómo preparas tus deltas de SQL? ¿guarda manualmente cada SQL de cambio de esquema en una carpeta delta, o tiene algún tipo de proceso de diferenciación automatizado?

Estoy interesado en las convenciones para versionar el esquema de la base de datos junto con el código fuente. ¿Quizás un gancho previo a la confirmación que diferencie el esquema?

Además, qué opciones existen para diferenciar deltas aparte de DbDeploy ?

EDITAR: ver las respuestas, me gustaría aclarar que estoy familiarizado con el esquema estándar para ejecutar una migración de base de datos usando deltas. Mi pregunta es sobre la creación de 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 de Ruby por favor).

Ver

¿Existe un sistema de control de versiones para los cambios en la estructura de la base de datos?

¿Cómo versiono mi base de datos MS SQL en SVN?

y el artículo de Jeff

Obtenga su base de datos bajo control de versiones

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

Mecanismos para rastrear cambios en el esquema de la base de datos

En general, siento que no hay una solución adecuada y aceptada para esto, y me pongo en práctica en esta área.

Puede echar un vistazo a otro hilo similar: ¿Cómo versiono mi base de datos MS SQL en SVN? .

Si todavía está buscando opciones: eche un vistazo a neXtep designer. Es un entorno de desarrollo de base de datos GPL gratuito basado en los conceptos de control de versiones. En el entorno, siempre trabaja con entidades versionadas y puede centrarse en el desarrollo del modelo de datos. Una vez que se realiza una versión, 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 y sincronizar inversamente su base de datos durante los desarrollos, crear diagramas de modelos de datos, consultar su base de datos utilizando clientes SQL integrados, etc.

Echa 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.

Me aseguro de que los cambios de esquema sean siempre aditivos. Por lo tanto, no elimino columnas y tablas, porque eso eliminaría los datos y no se puede revertir más tarde. De esta forma, el código que usa la base de datos puede revertirse sin perder datos o funcionalidad.

Tengo un script de migración que contiene declaraciones que crean tablas y columnas si aún no existen y las llena de datos.

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

Cuando me gustaría soltar algo, lo hago quitándolos del script de instalación de la base de datos y del script de migración para que estos elementos de esquema obsoletos se eliminen gradualmente en las nuevas instalaciones. Con la desventaja de que las nuevas instalaciones no pueden degradar a una versión anterior antes de la instalación.

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

No manejo deltas. Realizo cambios en una base de datos maestra y tengo una herramienta que crea un script de compilación basado en XML basado en la base de datos maestra.

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

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

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

No mencionó qué RDBMS está utilizando, pero si se trata de MS SQL Server, SQL Compare de Red-Gate ha sido indispensable para nosotros al crear deltas entre scripts de creación de objetos.

No soy de los que tocan mi propia bocina, pero he desarrollado una aplicación web interna para rastrear los cambios en los esquemas de la base de datos y crear scripts de actualización versionados.

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

Se planifica el soporte para poner los scripts de actualización en el control de versiones.

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

Exportamos los datos a un formato portátil (usando nuestra cadena de herramientas) y luego los importamos a un nuevo esquema. no hay necesidad de delta SQL. Muy recomendable.

Uso la base de datos Firebird para la mayoría del desarrollo y uso FlameRobin herramienta de administración para ello. Tiene una buena opción para registrar todos los cambios. Puede registrar todo en un archivo grande o un archivo por cambio de base de datos. 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 puede encontrar alguna herramienta MySQL que tenga la misma función de registro que FlameRobin para Firebird.

En una de las tablas de la base de datos, almaceno el número de versión de de la estructura de la base de datos, para poder actualizar cualquier base de datos fácilmente. También escribí un script PHP simple que ejecuta esos scripts SQL uno por uno en cualquier base de datos de destino (la ruta de la base de datos y el nombre de usuario / contraseña se proporcionan en la línea de comandos).

También hay una opción para registrar todas las declaraciones DML (insertar, actualizar eliminar), y activo esto mientras modifico algunos datos 'predeterminados' que contiene cada base de datos.

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

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

En una de las tablas de la base de datos (llamada TBSYNCHRONIZE), almaceno el número de versión del último script ejecutado, para poder actualizar cualquier base de datos fácilmente utilizando la interfaz web o un cliente desarrollado a propósito para Eclipse.

La interfaz web permite gestionar varios proyectos. Es compatible también con la base de datos "sucursales".

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

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

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

Pero ninguno de ellos cumplió mis requisitos.

Mis requisitos:

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

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

Por favor, pruébalo si te interesa este tema. Por favor envíeme futuras solicitudes y reportes de errores.

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

Yo uso http://code.google.com/p/oracle-ddl2svn/

También estoy interesado en este tema.

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

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

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 script 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, verifico los datos, tabla por tabla con mysqldiff. Es un poco arcaico, pero un bucle php basado en information_schemadatos hace que el trabajo sea seguro

Para el control de versiones, lo uso de la misma manera, pero formateo un script de actualización de SQL (para actualizar o revertir) con resultados de diferencias y uso la convención 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 base de datos (seguido en una tabla separada). Las secuencias de comandos se almacenan en el control de versiones, pero todas verifican la versión actual del esquema antes de realizar cualquier cambio.

Aquí está la implementación completa para SQL Server (la misma solución podría desarrollarse para MySQL si es necesario): Cómo mantener la versión del esquema de base de datos de SQL Server

Después de una larga investigación, descubrí que hay algunas herramientas de terceros o tipos de proyectos de Visual Studio que no me satisfacen, o simplemente bloguea sobre la teoría pero no implementa. Así que implementé un sistema de trabajo, que se usa casi un año, y lo expliqué aquí:

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

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