Como um grupo pode rastrear alterações no esquema do banco de dados?

Quais metodologias de controle de versão ajudam equipes de pessoas a rastrear alterações no esquema do banco de dados?

Apenas alguns minutos atrás, eu estava checando o seguinte: Uma tabela que deveria existir em todos os projetos com um banco de dados parece simples o suficiente para colocar em prática, confira:

Ele se chama schema_version (ou migrações, ou o que mais lhe convier) e seu objetivo é acompanhar as alterações estruturais ou de dados no banco de dados. Uma estrutura possível (exemplo no MySQL) é:

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

insira valores schema_version ( key, extra) ('001', 'versão do esquema');

A decisão de adicionar esta tabela desde o início do projeto ou logo após a implantação da primeira versão em um servidor de temporariedade ou produção depende de você.

Sempre que você precisar executar um script SQL para alterar a estrutura do banco de dados ou executar uma migração de dados, adicione uma linha nessa tabela também. E faça isso por meio de uma instrução insert no início ou no final desse script (que é confirmado no repositório de códigos do projeto).

...

Eu acho que o melhor método é ter o banco de dados gerado como parte do seu processo de compilação . Mantenha todos os scripts no controle de origem com o restante do código, e todos são responsáveis ​​por seus próprios ambientes.

Caso contrário, o RedGate possui uma ferramenta para integrar o controle de origem no SSMS e o SQL Compare é útil para comparar / sincronizar esquemas do MS SQL Server. O Visual Studio Database Edition também possui uma ferramenta de comparação de esquema interna .

Outra pergunta do SO me levou ao Migrator Dot Net, que vou começar a investigar durante meu copioso tempo livre. Parece um bom método, mas pode ser mais um investimento de tempo / despesas gerais do que você deseja fazer.

eiefai já mencionado Uma tabela que deve existir em todos os projetos com um banco de dados . Este é um ótimo post no blog, mas na IMO ele apenas parte do caminho para uma solução funcional para controle de revisão de banco de dados. Eu acho que qualquer tentativa de "responder" a essa pergunta no mundo real precisa considerar algumas das outras informações sobre VCS e bancos de dados:

• A metodologia Agile Data
• O livro "Refatoração de banco de dados"
• Artigo de Martin Fowler sobre "Design de banco de dados evolucionário"
• A ferramenta Liquibase
• Um vídeo decente com Scott Ambler apresentando seus pensamentos sobre "Bancos de Dados Agile"

Existem alguns ângulos diferentes para abordar essa questão, eu acho. O ângulo "primeiro a ferramenta", acredito, vai variar com base na plataforma e nas preferências pessoais. Caso em questão: estou usando um projeto de banco de dados no MS Visual Studio, mas não tenho certeza de que essa seja uma ótima solução para o MySQL. Também conheço pessoas que são bem vendidas em suas ferramentas favoritas de Redgate, Erwin, Embarcadero, etc.

Há também um ângulo de "processo primeiro" para esta pergunta, que (espero) será revisado neste site em perguntas subsequentes. As principais chaves desse processo estão colocando seu esquema sob controle de origem e gerenciando alterações, de modo que você pode aplicar alterações de esquema da versão "x" para a versão "y" praticamente sob demanda.

Uma resposta definitiva para este tópico vai acabar parecendo um livro, por isso provavelmente vale a pena começar com a referência a um: Redgate publicou recentemente um ebook gratuito chamado " O Guia do Red Gate para o Desenvolvimento em Equipe do SQL Server ", e enquanto houver há muito para ser debatido, é um bom lugar para começar a debater, IMO. Ao contrário do nome, grande parte do material deste livro é geral o suficiente para aplicar a qualquer banco de dados (não apenas o SQL Server) e a qualquer conjunto de ferramentas (não apenas o Redgate). Se você ainda não viu isso, definitivamente vale a pena, pelo menos.

Por fim, provavelmente vale a pena vincular a "resposta herdada" do stackoverflow .

SchemaCrawler é minha ferramenta para produzir um arquivo de texto com todos os objetos de esquema do banco de dados. Eu projetei essa saída de texto para ser legível por humanos, além de ser diferente da saída semelhante de outro servidor.

Na prática, o que descobri é que a saída de um arquivo de texto do esquema do banco de dados é útil, quando realizada como parte da compilação. Dessa forma, você pode verificar o arquivo de texto no seu sistema de controle de código-fonte e ter um histórico de versão de como seu esquema evoluiu ao longo do tempo. O SchemaCrawler foi projetado para automatizar isso também, na linha de comando.