Estou tentando criar (ou encontrar) um sistema reutilizável para versionamento de esquema de banco de dados em projetos php.

Existem vários projetos de migração no estilo Rails disponíveis para php.http://code.google.com/p/mysql-php-migrations/ é um bom exemplo Ele usa carimbos de data e hora para arquivos de migração, o que ajuda com conflitos entre ramificações.

Problema geral com este tipo de sistema: Quando o ramo de desenvolvimento A está com check-out e você deseja fazer check-out do ramo B, B pode ter novos arquivos de migração. Tudo bem, a migração para o conteúdo mais recente é simples.

Se a ramificação A tiver arquivos de migração mais recentes, você precisará migrar para baixo para o patch compartilhado mais próximo. Se as ramificações A e B tiverem bases de código significativamente diferentes, talvez seja necessário migrar ainda mais. Isso pode significar: Confira B, determine o número do patch compartilhado, confira A, migre para baixo para este patch. Isso deve ser feito em A, pois os patches aplicados reais não estão disponíveis em B. Em seguida, faça o checkout da ramificação B e migre para o mais recente patch B. Inverta o processo novamente ao passar de B para A.

Sistema proposto: Ao migrar para cima, em vez de apenas armazenar a versão do patch, serialize todo o patch no banco de dados para uso posterior, embora eu provavelmente precise apenas do método down (). Ao alterar ramificações, compare as correções executadas com as disponíveis na ramificação de destino. Determine o patch compartilhado mais próximo (ou a diferença mais antiga, talvez) entre a tabela db de patches de execução e patches na ramificação de destino por ID ou hash. Também é possível procurar por patches novos ou ausentes, ocultos sob vários patches compartilhados entre os dois ramos.

Mesclar automaticamente para o patch compartilhado mais próximo, usando os métodos de tabela db armazenados down () e, em seguida, mesclar para o patch mais recente da ramificação.

Minha pergunta é: Esse sistema é muito louco e / ou cheio de consequências para se preocupar em se desenvolver? Minha experiência com a versão do esquema de banco de dados é limitada ao autopatch do PHP, que é um sistema up () - apenas que requer nomes de arquivos com IDs seqüenciais.

Atualização, 2 anos depois

Esta é uma publicação antiga, mas eu queria mencionar que abandonei as migrações em geral durante o desenvolvimento, pois são desnecessariamente complicadas e propensas a erros.

Em vez disso, eu uso scripts de construção para:

limpe o banco de dados,crie o esquema,adicionar dados conhecidos do aplicativo (conteúdo real) eadicionar dados de fixação (conteúdo de desenvolvimento).

Ao alterar ramificações ou receber atualizações de outros desenvolvedores, você recarrega o banco de dados completamente com um comando para chegar a um estado conhecido.

Os servidores de produção ainda precisam de patches no banco de dados, mas eles precisariam ser criados manualmente de qualquer maneira.