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

Costumo encontrar o seguinte problema.

Trabalho em algumas alterações em um projeto que exigem novas tabelas ou colunas no banco de dados. Eu faço as modificações no banco de dados e continuo meu trabalho. Normalmente, lembro de anotar as alterações para que elas possam ser replicadas no sistema ativo. No entanto, nem sempre me lembro do que mudei e nem sempre lembro de anotá-las.

Então, eu empurro o sistema ao vivo e recebo um erro grande e óbvio de que não há NewColumnX, ugh.

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

No Ruby on Rails, existe o 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 o downgrade da versão (como remover uma coluna). Cada migração é numerada e uma tabela controla sua versão atual do banco de dados.

Para migrar , execute 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, faz check-in em um novo script e qualquer desenvolvedor pode aplicá-lo para trazer o banco de dados local para a versão mais recente.

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 os dados persistentes e o segundo para modificações. Obviamente, ambos estão sob controle de origem.

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

Além disso, normalmente tenho uma tabela no db - 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único é alterado quando o banco de dados é recriado e db_revisionfornece uma indicação de quão longe o banco de dados está da linha de base.

Eu poderia manter as atualizações em seus próprios arquivos separados, mas optei por juntá-las e usar recortar e colar para extrair seções relevantes. Um pouco mais de limpeza está em ordem, ou seja, remova ':' de $ Revisão 1.1 $ para congelá-los.

O MyBatis (anteriormente iBatis) possui uma ferramenta de migração de esquema para uso na linha de comando. Está escrito em java, mas pode ser usado com qualquer projeto.

Para alcançar uma boa prática de gerenciamento de alterações no banco de dados, precisamos identificar alguns objetivos principais. Assim, o Sistema de Migração do Esquema MyBatis (ou MyBatis Migrations, abreviado) procura:

• Trabalhe com qualquer banco de dados, novo ou existente
• Alavancar o sistema de controle de fonte (por exemplo, Subversion)
• Permitir que desenvolvedores ou equipes simultâneos trabalhem independentemente
• Permitir conflitos muito visíveis e facilmente gerenciáveis
• Permitir migração para frente e para trás (evoluir, devolver respectivamente)
• Tornar o status atual do banco de dados facilmente acessível e compreensível
• Habilitar migrações apesar dos privilégios de acesso ou burocracia
• Trabalhar com qualquer metodologia
• Incentiva boas práticas consistentes

Redgate tem um produto chamado SQL Source Control . Ele se integra ao TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce e Git.

Eu recomendo o delta do SQL . Eu apenas o uso para gerar os scripts diff quando terminar de codificar meu recurso e verificar esses scripts na minha ferramenta de controle de origem (Mercurial :))

Eles possuem um servidor SQL e uma versão Oracle.

Gostaria de saber que ninguém mencionou a ferramenta de código aberto liquibase que é baseada em Java e deve funcionar para quase todos os bancos de dados que suportam jdbc. Comparado aos trilhos, ele usa xml em vez de ruby ​​para executar as alterações no esquema. Embora eu não goste do xml em idiomas específicos do domínio, a vantagem muito legal do xml é que o liquibase sabe reverter certas operações como

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

Então você não precisa lidar com isso 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 a descarga do banco de dados em um arquivo. Eu sei que o MySQL faz, de qualquer maneira. Este será apenas um arquivo de texto, para que você possa enviá-lo ao Subversion, ou o que você usar. Também seria fácil executar um diff nos arquivos.

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

Há um vídeo instrutivo no MSDN que é 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.

Tenha suas instruções de criação de tabela inicial no controlador de versão e adicione instruções de alteração de tabela, mas nunca edite arquivos, apenas mais arquivos de alteração idealmente nomeados sequencialmente ou 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 é o rastreamento de dependências, por exemplo, para uma determinada tabela de implantação B pode precisar ser atualizada antes da tabela A.

Para Oracle, eu uso o Toad , que pode despejar um esquema em vários arquivos discretos (por exemplo, um arquivo por tabela). Eu tenho alguns scripts que gerenciam essa coleção no Perforce, mas acho que deve ser facilmente executável 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

Quando você estiver familiarizado com a forma 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 o MSSQL.

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

Eu faço isso há muitos anos - gerenciando (ou tentando gerenciar) versões de esquema. As melhores abordagens dependem das ferramentas que você possui. Se você pode obter a ferramenta "Schema Manager" da Quest Software, estará em boa forma. A Oracle tem sua própria ferramenta inferior, também chamada de "Schema Manager" (muito confusa?) Que eu 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 e siga-a rigorosamente. Eu gosto de ter a capacidade de recriar o banco de dados a qualquer momento, por isso prefiro ter uma exportação DDL completa de todo o banco de dados (se eu sou o DBA) ou do esquema do desenvolvedor (se eu estiver no produto modo de desenvolvimento).

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

Na web:

O plug-in de controle de versão fornece uma forte integração entre o PL / SQL Developer IDE >> e qualquer sistema de controle de versão que suporte a especificação de interface do 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

O ER Studio permite reverter o esquema do banco de dados na ferramenta e, em seguida, você pode compará-lo aos bancos de dados ativos.

Exemplo: inverta seu esquema de desenvolvimento no ER Studio - compare-o com a produção e ele listará todas as diferenças. Ele pode fazer o script das alterações ou simplesmente enviá-las automaticamente.

Depois de ter um esquema no ER Studio, você pode salvar o script de criação ou 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 enviar para sua plataforma db.

Existe uma "estrutura de migração de banco de dados" do PHP5 chamada Ruckusing. Eu não o usei, mas os exemplos mostram a idéia: se você usar o idioma para criar o banco de dados como e quando necessário, precisará rastrear apenas os arquivos de origem.

Você pode usar o Microsoft SQL Server Data Tools no visual studio para gerar scripts para objetos de banco de dados como parte de um projeto do 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 de banco de dados usando um compilador e gerar scripts de implantação para atualizar um banco de dados existente ou criar um novo.

Usamos o MS Team System Database Edition com muito bom sucesso. Ele se integra ao controle de versão do TFS e ao Visual Studio de maneira mais ou menos transparente e nos permite gerenciar procs, visualizações etc., facilmente. A resolução de conflitos pode ser um problema, mas o histórico de versões fica completo quando é feito. Posteriormente, as migrações para o controle de qualidade e a produção são extremamente simples.

É justo dizer que é um produto da versão 1.0, porém, e não deixa de ter alguns problemas.

O Schema Compare for Oracle é uma ferramenta projetada especificamente para migrar alterações do nosso banco de dados Oracle para outro. Visite o URL abaixo para 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, eu os registro em um wiki. Pelo menos então eu 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 do que nada.

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

A outra idéia é ativar a auditoria DDL (funciona no Oracle). Isso criará uma tabela com todas as alterações que você fizer. Se você consultar as alterações do carimbo de data e hora da última vez que as alterações do banco de dados foram movidas para prod agora, você terá uma lista ordenada de tudo o que fez. Algumas cláusulas where para eliminar alterações de soma zero, como criar tabela foo; seguido de drop table foo; e você pode facilmente criar 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 um aplicativo ASP com SQL Server, que estávamos no processo de mudança para o Rails. Você verifica os próprios scripts de migração no VCS. Aqui está um post de Pragmatic Dave Thomas sobre o assunto.