Controle de origem do banco de dados vs.scripts de mudança de esquema

Question

Construir e manter um banco de dados que é então implementado/desenvolvido por muitos desenvolvedores é algo que acontece no desenvolvimento de software o tempo todo.Criamos um script de construção e mantemos scripts de atualização adicionais que são aplicados à medida que o banco de dados cresce ao longo do tempo.Há muitas maneiras de gerenciar isso, desde atualizações manuais até aplicativos de console/scripts de construção que ajudam a automatizar esses processos.

Alguém que criou/gerenciou esses processos mudou para uma solução de controle de origem para gerenciamento de esquema de banco de dados?Em caso afirmativo, qual eles encontraram como a melhor solução?Existem armadilhas que devem ser evitadas?

Red Gate parece ser um grande player no mundo MSSQL e seu controle de origem de banco de dados parece muito interessante:http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

Embora não pareça substituir o processo de gerenciamento de dados (padrão)*, ele substitui apenas metade do processo de gerenciamento de mudanças do meu ponto de vista.

(quando falo sobre dados, quero dizer valores de pesquisa e esse tipo de coisa, dados que precisam ser implantados por padrão ou em um cenário de DR)

Trabalhamos em um ambiente .Net/MSSQL, mas tenho certeza de que a premissa é a mesma em todas as linguagens.

Answer 1

Perguntas semelhantes

Uma ou mais dessas perguntas existentes podem ser úteis:

• a melhor maneira de gerenciar as alterações do banco de dados
• MySQL Database Altere o rastreamento
• Database SQL Server alterar as melhores práticas de trabalho
• Verificar alterações de banco de dados (controle de versão)
• Transferência de alterações de um Dev DB para uma produção Db
• Mudanças de rastreamento feitas na estrutura do banco de dados

ou uma busca por Mudança de banco de dados

Answer 2

Cuido de um data warehouse desenvolvido internamente pelo banco onde trabalho.Isso requer atualização constante e temos uma equipe de 2 a 4 desenvolvedores trabalhando nisso.

Temos sorte porque existe apenas uma instância do nosso "produto", portanto não precisamos atender à implantação em várias instâncias, que podem estar em versões diferentes.

Mantemos um arquivo de script de criação para cada objeto (tabela, visão, índice, procedimento armazenado, gatilho) no banco de dados.

Evitamos o uso de ALTER TABLE sempre que possível, preferindo renomear uma tabela, crie a nova e migre os dados.Isso significa que não precisamos olhar através de uma história de ALTER scripts - sempre podemos ver a versão atualizada de cada tabela observando seu script de criação.A migração é executada por um script de migração separado - isso pode ser parcialmente gerado automaticamente.

Cada vez que fazemos um lançamento, temos um script que executa os scripts de criação/migração na ordem apropriada.

PARA SUA INFORMAÇÃO:Usamos Visual SourceSafe (eca!) para controle de código-fonte.

Answer 3

Eu tenho procurado uma ferramenta de controle de origem do SQL Server - e deu muitas versões premium que fazem o trabalho - usando o SQL Server Management Studio como um plugin.

Liquibase é um livre, mas eu nunca consegui trabalhar para minhas necessidades.

Há outro produto gratuito lá fora, embora o funcione fique junto de SSMS e scripts fora objetos e dados para arquivo simples.

Esses objetos podem ser bombeados em uma nova instância do SQL Server que irá recriar os objetos do banco de dados.

ver gitsql

Answer 4

talvez você esteja pedindo por Liquibase ?