Manipulando Alterações no Esquema do Banco de Dados ao Empurrar Novas Versões

Durante os tempos de desenvolvimento pesado, o esquema do banco de dados muda rápida e continuamente, e quando nosso envio semanal para a versão beta chega, o esquema mudou tanto que a única opção sensata é destruir todas as tabelas que posso e copie as novas versões do meu banco de dados dev. Obviamente, isso não vai funcionar assim que iniciarmos, já que os dados de produção de nuking são uma receita para o desastre, então eu queria saber quais estratégias existem para gerenciar as alterações do esquema do banco de dados de uma versão / revisão para outra?

Alguns que eu encontrei ou experimentei:

1. Nuke-and-dump direto de um banco de dados para outro (o que estou fazendo agora)
2. Manter um arquivo UPDATE.sql com instruções SQL executadas via script ou manualmente.
3. Mantendo um arquivo update.php com um valor "db-schema-version" correspondente no banco de dados ativo

A terceira opção parece ser a mais sensata, mas ainda existe a possibilidade de uma consulta SQL mal construída falhar no meio do script, deixando o banco de dados em um estado semi-atualizado, exigindo a restauração de um backup.

Parece um problema, mas acontece que, como equipe, usamos o phpMyAdmin, e não consigo confiar em mim mesmo, lembre-se de copiar a instrução SQL executada para colar no arquivo update.php. Depois de navegar para outra página, preciso reescrever a instrução SQL manualmente, ou reverter minhas alterações e fazê-lo novamente.

Acho que o que espero é uma solução que não afete nosso fluxo de trabalho de desenvolvimento estabelecido?

Automatizar. Automatizar. Automatizar.

Você está no caminho certo com um número de versão explícito do banco de dados, mas eu daria um passo adiante e tornaria o código explicitamente ciente de exatamente em qual esquema ele espera trabalhar (por exemplo, confirmando o script DDL real e fazendo com que o atualizador o analise ); no momento da atualização, você só precisará descobrir o esquema existente via metadados do banco de dados e INSERT / DROP / ALTER conforme necessário, independentemente de qual versão para qual versão você está atualizando. (Você também pode manter um número de versão explícito no próprio banco de dados e entregar todo o histórico do esquema com o instalador, para que você nem precise da descoberta do esquema.)

Erros de sintaxe em potencial no script SQL de atualização são um problema, mas você pode resolver isso verificando se o atualizador pode produzir apenas instruções DDL corretas. (As provas formais quase nunca valem a pena no desenvolvimento de software corporativo - muito esforço para garantir muito pouco - mas sinto que a integridade do banco de dados é uma das poucas exceções: SQL básico não é uma linguagem particularmente difícil de capturar formalmente, e o benefício de a proteção dos dados de produção é tão grande que quase qualquer quantidade de esforço inicial é justificada, principalmente se for necessário trabalhar para instalações autônomas)

A versão do esquema do banco de dados é o caminho a seguir - cada versão possui apenas uma alteração no banco de dados ou pelo menos alterações que podem ser revertidas como um todo. O DBDeploy é uma ótima ferramenta para automatizar isso.

Algumas coisas que aprendi úteis são:

1. Sempre teste sua alteração localmente e teste seu código com ela, apenas a ALTERpassagem não é suficiente
2. Você precisa sincronizar quais mudanças são necessárias primeiro - uma simples página wiki na qual é possível "obter um número" que funcionou muito bem para minha equipe.
3. Não tente corrigir alterações quebradas, adicione uma nova contra-alteração para negá-la, é muito indolor
4. Seu código depende dessas alterações - certifique-se de vincular os problemas no seu sistema de rastreamento de erros às alterações no banco de dados. Isso é muito útil no momento da implantação.
5. Incluir alterações de banco de dados no seu IC - aplique suas alterações a um banco de dados de IC ao confirmar. Além disso, se você tiver algum teste que use um banco de dados, execute-o no commit.

Como você está usando o phpMyAdmin, suponho que você também esteja usando o MySQL.

Dê uma olhada nos diagramas do modelo EER no MySQL Workbench. Eles me ajudaram muito na manutenção e atualização de esquemas.

Primeiro, você pode sincronizar o modelo com uma fonte de banco de dados. Para que as alterações no diagrama sejam enviadas como comandos ALTER TABLE. Isso permite que você execute as alterações do esquema no diagrama, mantenha-o sempre atualizado e, ao mesmo tempo, atualize o banco de dados de desenvolvimento, quando necessário.

Em segundo lugar, você pode fazer engenharia reversa de um diagrama EER a partir de uma fonte de banco de dados. O que pode ser útil, fazendo alterações em um banco de dados de desenvolvimento e atualizando um banco de dados de produção, pois ele calculará as diferenças.

Em terceiro lugar, ele pode ser usado para ajudar na criação do SQL que deve entrar no seu arquivo "update.sql".

CONTRAS:

Os gatilhos e restrições do banco de dados são um problema com o atualizador de sincronização. Parece não saber a ordem certa das coisas. As restrições de chave estrangeira geralmente geram erros, mas isso pode ser resolvido editando o SQL gerado.

Esta não é uma ferramenta de migração de dados. Quaisquer alterações que estejam além do esquema puramente ainda precisarão de SQL personalizado.

Dê uma olhada em http://south.aeracode.org - é uma biblioteca de migrações de banco de dados para o Django (uma estrutura Python), mas:

1. você pode obter ótimas idéias (e talvez até encontrar um clone do PHP)
2. você pode realmente usá-lo independentemente do resto do Django para gerenciar as tabelas do seu aplicativo PHP / MySQL.

Também pode gerar scripts de atualização de esquema; Ele também lida com reversões de alterações automaticamente na maioria das vezes.