Existe um sistema de controle de versão para alterações na estrutura do banco de dados?

08-06-2019
|

Pergunta

Muitas vezes me deparo com o seguinte problema.

Trabalho em algumas alterações em um projeto que exigem novas tabelas ou colunas no banco de dados.Faço as modificações no banco de dados e continuo meu trabalho.Normalmente, lembro-me de anotar as alterações para que possam ser replicadas no sistema ativo.Porém, nem sempre me lembro do que mudei e nem sempre me lembro de anotar.

Então, eu faço um push para o sistema ativo e recebo um erro grande e óbvio de que não há NewColumnX, eca.

Independentemente de esta não ser a melhor prática para esta situação, existe um sistema de controle de versão para bancos de dados?Não me importo com a tecnologia específica do banco de dados.Eu só quero saber se existe algum.Se funcionar com o MS SQL Server, ótimo.

Solução

Em Ruby on Rails, existe um conceito de migração -- um script rápido para alterar o banco de dados.

Você gera um arquivo de migração, que possui regras para aumentar a versão do banco de dados (como adicionar uma coluna) e regras para fazer downgrade da versão (como remover uma coluna).Cada migração é numerada e uma tabela monitora sua versão atual do banco de dados.

Para migrar para cima, você executa um comando chamado "db:migrate" que analisa sua versão e aplica os scripts necessários.Você pode migrar para baixo de maneira semelhante.

Os próprios scripts de migração são mantidos em um sistema de controle de versão - sempre que você altera o banco de dados, você faz check-in de um novo script, e qualquer desenvolvedor pode aplicá-lo para trazer seu banco de dados local para a versão mais recente.

Outras dicas

Sou um pouco antiquado, pois uso arquivos de origem para criar o banco de dados.Na verdade, existem 2 arquivos - project-database.sql e project-updates.sql - o primeiro para o esquema e dados persistentes e o segundo para modificações.Claro, ambos estão sob controle de origem.

Quando o banco de dados muda, primeiro atualizo o esquema principal em project-database.sql e, em seguida, copio as informações relevantes para project-updates.sql, por exemplo, instruções ALTER TABLE.Posso então aplicar as atualizações ao banco de dados de desenvolvimento, testar, iterar até ficar bem feito.Em seguida, faça check-in dos arquivos, teste novamente e aplique à produção.

Além disso, normalmente tenho uma tabela no banco de dados - Config - como:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Em seguida, adiciono o seguinte à seção de atualização:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

O db_version só é alterado quando o banco de dados é recriado, e o db_revision me dá uma indicação de quão longe o banco de dados está fora da linha de base.

Eu poderia manter as atualizações em seus próprios arquivos separados, mas optei por combiná-las todas e usar recortar e colar para extrair seções relevantes.Um pouco mais de limpeza é necessário, ou seja, remova ':' de $Revision 1.1 $ para congelá-los.

Meu Batis (anteriormente iBatis) tem um migração de esquema, ferramenta para uso na linha de comando.Está escrito em java, mas pode ser usado em qualquer projeto.

Para alcançar uma boa prática de gerenciamento de alterações de banco de dados, precisamos identificar alguns objetivos principais.Assim, o MyBatis Schema Migration System (ou MyBatis Migrations, abreviadamente) busca:

Trabalhe com qualquer banco de dados, novo ou existente
Aproveite o sistema de controle de origem (por exemplo,Subversão)
Permita que desenvolvedores ou equipes simultâneas trabalhem de forma independente
Permitir conflitos muito visíveis e facilmente gerenciáveis
Permitir migração para frente e para trás (evoluir, devolver respectivamente)
Torne o status atual do banco de dados facilmente acessível e compreensível
Permitir migrações apesar de privilégios de acesso ou burocracia
Trabalhe com qualquer metodologia
Incentiva práticas boas e consistentes

Redgate tem um produto chamado Controle de origem SQL.Ele se integra com TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce e Git.

Eu recomendo Delta SQL.Eu apenas o uso para gerar os scripts diff quando termino de codificar meu recurso e verifico esses scripts em minha ferramenta de controle de origem (Mercurial :))

Eles têm um servidor SQL e uma versão Oracle.

Eu me pergunto se ninguém mencionou a ferramenta de código aberto liquidbase que é baseado em Java e deve funcionar para quase todos os bancos de dados que suportam jdbc.Comparado ao Rails, ele usa xml em vez de Ruby para realizar as alterações de esquema.Embora eu não goste de xml para linguagens específicas de domínio, a vantagem muito interessante do xml é que o liquibase sabe como reverter certas operações como

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Então você não precisa cuidar disso sozinho

Instruções SQL puras ou importações de dados também são suportadas.

A maioria dos mecanismos de banco de dados deve suportar o despejo do seu banco de dados em um arquivo.Eu sei que o MySQL faz, de qualquer maneira.Este será apenas um arquivo de texto, então você poderá enviá-lo ao Subversion ou a qualquer outro arquivo que usar.Seria fácil fazer uma comparação nos arquivos também.

Se você estiver usando o SQL Server, será difícil vencer o Data Dude (também conhecido como Database Edition do Visual Studio).Depois de pegar o jeito, é muito fácil fazer uma comparação de esquema entre a versão do banco de dados controlada pela origem e a versão em produção.E com um clique você pode gerar seu DDL diferencial.

Há uma instrução vídeo no MSDN isso é muito útil.

Eu sei sobre DBMS_METADATA e Toad, mas se alguém pudesse criar um Data Dude para Oracle, a vida seria muito boa.

Faça com que suas instruções iniciais de criação de tabela sejam criadas no controlador de versão e, em seguida, adicione instruções de alteração de tabela, mas nunca edite arquivos, apenas altere mais arquivos idealmente nomeados sequencialmente ou até mesmo como um "conjunto de alterações", para que você possa encontrar todas as alterações para uma implantação específica.

A parte mais difícil que posso ver é rastrear dependências, por exemplo, para uma implantação específica, a tabela B pode precisar ser atualizada antes da tabela A.

Para Oracle, eu uso Sapo, que pode despejar um esquema em vários arquivos discretos (por exemplo, um arquivo por tabela).Tenho alguns scripts que gerenciam essa coleção no Perforce, mas acho que isso deve ser facilmente executado em praticamente qualquer sistema de controle de revisão.

Dê uma olhada no pacote oracle DBMS_METADATA.

Em particular, os seguintes métodos são particularmente úteis:

DBMS_METADATA.GET_DDL
DBMS_METADATA.SET_TRANSFORM_PARAM
DBMS_METADATA.GET_GRANTED_DDL

Depois de estar familiarizado com como eles funcionam (bastante autoexplicativo), você pode escrever um script simples para despejar os resultados desses métodos em arquivos de texto que podem ser colocados sob controle de origem.Boa sorte!

Não tenho certeza se existe algo tão simples para MSSQL.

Eu escrevo meus scripts de lançamento do banco de dados em paralelo com a codificação e mantenho os scripts de lançamento em uma seção específica do projeto no SS.Se eu fizer uma alteração no código que exija uma alteração no banco de dados, atualizo o script de lançamento ao mesmo tempo.Antes do lançamento, executo o script de lançamento em um banco de dados de desenvolvimento limpo (estrutura copiada da produção) e faço meus testes finais nele.

Eu faço isso há anos - gerenciando (ou tentando gerenciar) versões de esquema.As melhores abordagens dependem das ferramentas que você possui.Se você conseguir a ferramenta Quest Software "Schema Manager", você estará em boa forma.A Oracle tem sua própria ferramenta inferior, também chamada de "Schema Manager" (confunde muito?) Que não recomendo.

Sem uma ferramenta automatizada (veja outros comentários aqui sobre o Data Dude), você usará scripts e arquivos DDL diretamente.Escolha uma abordagem, documente-a e siga-a rigorosamente.Gosto de poder recriar o banco de dados a qualquer momento, então prefiro ter uma exportação DDL completa de todo o banco de dados (se eu for o DBA) ou do esquema do desenvolvedor (se estiver no produto -modo de desenvolvimento).

PLSQL Developer, uma ferramenta da All Arround Automations, possui um plugin para repositórios que funciona bem (mas não muito bem) com o Visual Source Safe.

Da web:

O plug-in de controle de versão fornece uma forte integração entre o IDE do desenvolvedor PL/SQL >> e qualquer sistema de controle de versão que suporte a especificação de interface Microsoft SCC.>>Isso inclui os sistemas de controle de versão mais populares, como Microsoft Visual SourceSafe, >>Merant PVCS e MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

Estúdio de emergência permite reverter o esquema do banco de dados na ferramenta e compará-lo com bancos de dados ativos.

Exemplo:Reverta seu esquema de desenvolvimento para o ER Studio - compare-o com a produção e ele listará todas as diferenças.Ele pode criar scripts para as alterações ou simplesmente enviá-las automaticamente.

Depois de ter um esquema no ER Studio, você pode salvar o script de criação ou salvá-lo como um binário proprietário e salvá-lo no controle de versão.Se você quiser voltar para uma versão anterior do esquema, basta dar uma olhada e enviá-lo para sua plataforma de banco de dados.

Existe uma "estrutura de migração de banco de dados" PHP5 chamada Ruckusing.Eu não usei, mas o exemplos Para mostrar a ideia, se você usar a linguagem para criar o banco de dados como e quando necessário, basta rastrear os arquivos de origem.

Você pode usar Ferramentas de dados do Microsoft SQL Server no visual studio para gerar scripts para objetos de banco de dados como parte de um projeto SQL Server.Em seguida, você pode adicionar os scripts ao controle de origem usando a integração de controle de origem incorporada ao visual studio.Além disso, os projetos do SQL Server permitem verificar os objetos do banco de dados usando um compilador e gerar scripts de implantação para atualizar um banco de dados existente ou criar um novo.

Nós usamos Edição de banco de dados MS Team System com bastante sucesso.Ele se integra ao controle de versão do TFS e ao Visual Studio de maneira mais ou menos perfeita e nos permite gerenciar facilmente processos, visualizações, etc. armazenados.A resolução de conflitos pode ser uma dor, mas o histórico da versão estará completo assim que for concluído.Depois disso, as migrações para controle de qualidade e produção são extremamente simples.

É justo dizer que é um produto da versão 1.0 e tem alguns problemas.

Schema Compare for Oracle é uma ferramenta projetada especificamente para migrar alterações de nosso banco de dados Oracle para outro.Visite o URL abaixo para obter o link de download, onde você poderá usar o software para uma avaliação totalmente funcional.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Na ausência de um VCS para alterações de tabela, estou registrando-as em um wiki.Pelo menos posso ver quando e por que foi alterado.Está longe de ser perfeito, pois nem todo mundo está fazendo isso e temos várias versões de produtos em uso, mas é melhor que nada.

Eu recomendaria uma das duas abordagens.Primeiro, invista em PowerDesigner da Sybase.Edição Empresarial.Ele permite projetar modelos de dados físicos e muito mais.Mas ele vem com um repositório que permite fazer check-in de seus modelos.Cada novo check in pode ser uma nova versão, pode comparar qualquer versão com qualquer outra versão e até mesmo com o que está no seu banco de dados naquele momento.Ele então apresentará uma lista de todas as diferenças e perguntará quais devem ser migradas… e então construirá o script para fazer isso.Não é barato, mas é uma pechincha pelo dobro do preço e seu ROI é de cerca de 6 meses.

A outra ideia é ativar a auditoria DDL (funciona no Oracle).Isso criará uma tabela com cada alteração feita.Se você consultar as alterações do carimbo de data e hora para o qual você moveu as alterações do banco de dados para prod pela última vez, você terá uma lista ordenada de tudo o que fez.Algumas cláusulas where para eliminar alterações de soma zero, como create table foo;seguido por drop table foo;e você pode FACILMENTE construir um script mod.Por que manter as alterações em um wiki, isso é o dobro do trabalho.Deixe o banco de dados rastreá-los para você.

Duas recomendações de livros:"Refactoring Databases" de Ambler e Sadalage e "Agile Database Techniques" de Ambler.

Alguém mencionou Migrações Rails.Eu acho que eles funcionam muito bem, mesmo fora dos aplicativos Rails.Eu os usei em uma aplicação ASP com SQL Server que estávamos migrando para Rails.Você verifica os próprios scripts de migração no VCS.Aqui está uma postagem do pragmático Dave Thomas sobre o assunto.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow