Estoy tratando de encontrar (o encontrar) un sistema reutilizable para el control de versiones de esquemas de bases de datos en proyectos php.

Hay varios proyectos de migración al estilo Rails disponibles para php.http://code.google.com/p/mysql-php-migrations/ Es un buen ejemplo. Utiliza marcas de tiempo para los archivos de migración, lo que ayuda con los conflictos entre las ramas.

Problema general con este tipo de sistema: Cuando la rama de desarrollo A está desprotegida, y usted desea desproteger la rama B, B puede tener nuevos archivos de migración. Esto está bien, migrar a contenido más nuevo es sencillo.

Si la rama A tiene archivos de migración más nuevos, necesitaría migrar hacia abajo al parche compartido más cercano. Si las ramas A y B tienen bases de código significativamente diferentes, es posible que deba migrar hacia abajo aún más. Esto puede significar: echa un vistazo a B, determina el número de parche compartido, mira A, migra hacia abajo a este parche. Esto debe hacerse desde A, ya que los parches aplicados reales no están disponibles en B. Luego, desproteja la rama B y migre al parche B más nuevo. Invierta el proceso nuevamente cuando vaya de B a A.

Sistema propuesto: Al migrar hacia arriba, en lugar de solo almacenar la versión del parche, serialice todo el parche en la base de datos para su uso posterior, aunque probablemente solo necesite el método down (). Al cambiar ramas, compare los parches que se han ejecutado con los parches disponibles en la rama de destino. Determine el parche compartido más cercano (o la diferencia más antigua, tal vez) entre la tabla db de parches de ejecución y los parches en la rama de destino por ID o hash. También podría buscar parches nuevos o faltantes que están enterrados bajo varios parches compartidos entre las dos ramas.

Combinar automáticamente al parche compartido más cercano, utilizando los métodos de la tabla db almacenada down (), y luego combinar al último parche de la sucursal.

Mi pregunta es: ¿Es este sistema demasiado loco y / o cargado de consecuencias para molestarse en el desarrollo? Mi experiencia con el control de versiones del esquema de la base de datos se limita al parche automático de PHP, que es un sistema up () solo que requiere nombres de archivo con ID secuenciales.

Actualización, 2 años después

Esta es una publicación antigua, pero quería mencionar que abandoné las migraciones en general durante el desarrollo, ya que son innecesariamente complicadas y propensas a errores.

En cambio, uso scripts de compilación para:

borrar la base de datos,crea el esquema,agregar datos conocidos de la aplicación (contenido real) yagregar datos de accesorios (contenido de desarrollo).

Al cambiar de sucursal o al recibir actualizaciones de otros desarrolladores, vuelve a cargar la base de datos por completo con un comando para llegar a un estado conocido.

Los servidores de producción todavía necesitan parches de base de datos, pero de todos modos tendrían que crearse manualmente.