Mecanismos de alterações de esquema de rastreamento DB

votos
128

Quais são os melhores métodos para monitoramento e / ou automatizar as alterações de esquema DB? Nossa equipe usa Subversion para controle de versão e temos sido capazes de automatizar algumas das nossas tarefas desta forma (empurrando acumula-se a um servidor de teste, a implantação de código testado para um servidor de produção), mas nós ainda estamos fazendo atualizações do banco de dados manualmente. Gostaria de encontrar ou criar uma solução que nos permite trabalhar de forma eficiente em todos os servidores com diferentes ambientes, continuando a usar o Subversion como um backend através do qual atualizações de código e DB são empurrados para vários servidores.

Muitos pacotes de software populares incluir scripts de atualização automática, que detectam versão DB e aplicar as mudanças necessárias. É esta a melhor maneira de fazer isso, mesmo em maior escala (em vários projetos e, por vezes, vários ambientes e linguagens)? Se assim for, há algum código existente lá fora, que simplifica o processo ou é melhor apenas para rolar a nossa própria solução? Alguém já implementado algo semelhante antes e integrá-lo em Subversion ganchos post-commit, ou isso é uma má idéia?

Enquanto uma solução que suporta múltiplas plataformas seria preferível, nós definitivamente necessidade de apoiar o / Apache / MySQL pilha / PHP Linux como a maioria do nosso trabalho é nessa plataforma.

Publicado 04/08/2008 em 22:31
fonte usuário
Em outras línguas...                            


20 respostas

votos
54

No mundo do Rails, há o conceito de migrações, scripts em que as mudanças no banco de dados são feitos em Ruby em vez de um sabor específico do banco de dados de SQL. Seu código de migração Rubi acaba sendo convertido na DDL específico para o seu banco de dados atual; isso faz com que a mudança plataformas de banco de dados muito fácil.

Para cada alteração feita no banco de dados, você escrever uma nova migração. Migrações têm tipicamente dois métodos: um "up" método em que as alterações são aplicadas e um método "para baixo", em que as alterações são desfeitas. Um único comando traz o banco de dados até à data, e também pode ser usado para trazer o banco de dados para uma versão específica do esquema. No Rails, as migrações são mantidos em seu próprio diretório no diretório do projeto e começar verificado no controle de versão como qualquer outro código do projeto.

Este guia Oracle para Rails migrações cobre migrações muito bem.

Os desenvolvedores que usam outras linguagens de ter olhado para as migrações e implementaram suas próprias versões específicas do idioma. Eu sei de Ruckusing , um sistema de migrações PHP que é modelado após migrações Rails'; ele pode ser o que você está procurando.

Respondeu 04/08/2008 em 23:45
fonte usuário

votos
48

Nós usamos algo semelhante a bcwoord para manter os nossos esquemas de banco de dados sincronizados em 5 instalações diferentes (produção, preparo e algumas instalações de desenvolvimento), e apoiado no controle de versão, e ele funciona muito bem. Eu vou elaborar um pouco:


Para sincronizar a estrutura de banco de dados, temos um único script, update.php, e uma série de arquivos numerados 1.sql, 2.sql, 3.sql, etc. O script usa uma tabela extra para armazenar o número da versão atual do base de dados. Os arquivos N.sql são trabalhada à mão, para ir de versão (N-1) para a versão N do banco de dados.

Eles podem ser usados ​​para adicionar tabelas, adicionar colunas, migrar dados a partir de um antigo para um novo formato de coluna, em seguida, descartar a coluna, inserir linhas de dados "mestre", como tipos de usuário, etc. Basicamente, ele pode fazer qualquer coisa, e com dados adequada scripts de migração que você nunca vai perder dados.

O script de atualização funciona assim:

  • Conecte-se ao banco de dados.
  • Faça um backup do banco de dados atual (porque coisas vão dar errado) [mysqldump].
  • Criar tabela de contabilidade (chamada _meta) se ele não existe.
  • Leia versão atual da tabela _meta. Suponha 0 se não for encontrado.
  • Para todos os arquivos .sql numeradas maior do que VERSÃO, executá-los, a fim
  • Se um dos arquivos produzido um erro: reverter para o backup
  • Caso contrário, atualizar a versão na tabela de contabilidade para o mais alto ficheiro.sql executado.

Tudo vai para controle de origem, e cada instalação tem um script para atualizar para a versão mais recente com uma única execução do script (chamando update.php com o bom banco de dados de senha etc.). Nós SVN atualização de teste e ambientes de produção por meio de um script que chama automaticamente o script de atualização de banco de dados, assim que uma atualização de código vem com as atualizações do banco de dados necessárias.

Também pode usar o mesmo script para recriar todo o banco de dados a partir do zero; nós apenas eliminar e recriar o banco de dados, em seguida, executar o script que irá repovoar completamente o banco de dados. Podemos também usar o script para preencher um banco de dados vazio para testes automatizados.


Levou apenas algumas horas para configurar este sistema, é conceitualmente simples e todo mundo fica o esquema de numeração de versão, e tem sido inestimável para ter a capacidade de avançar e evoluir o design de banco de dados, sem ter de se comunicar ou manualmente executar as modificações em todos os bancos de dados.

Cuidado ao colar consultas de phpMyAdmin embora! Essas consultas geradas geralmente incluem o nome do banco, que você definitivamente não quer uma vez que vai quebrar seus scripts! Algo como CREATE TABLE mydb. newtable(...) falhará se o banco de dados no sistema não é chamado mydb. Nós criamos um gancho SVN pré-comentário que não permitirá arquivos contendo o .sql mydbcorda, que é um sinal claro de que alguém copiar / colar de phpMyAdmin sem verificação adequada.

Respondeu 22/08/2008 em 15:44
fonte usuário

votos
11

Meus scripts equipe fora todas as alterações de banco de dados, e compromete os scripts para SVN, juntamente com cada versão do aplicativo. Isto permite mudanças incrementais do banco de dados, sem perder quaisquer dados.

Para ir de uma versão para a próxima, você só precisa executar o conjunto de scripts de alteração, e seu banco de dados é up-to-date, e você ainda tem todos os seus dados. Pode não ser o método mais fácil, mas definitivamente é eficaz.

Respondeu 05/08/2008 em 20:56
fonte usuário

votos
9

Se você ainda está à procura de soluções: estamos propondo uma ferramenta chamada Nextep designer. É um ambiente de desenvolvimento de banco de dados com o qual você pode colocar todo o seu banco de dados sob controle de versão. Você trabalha em um repositório de controle de versão, onde cada mudança pode ser rastreado.

Quando você precisa para lançar uma atualização, você pode cometer seus componentes eo produto irá gerar automaticamente o script de atualização do SQL da versão anterior. Claro, você pode gerar esse SQL de quaisquer 2 versões.

Então você tem muitas opções: você pode tomar esses scripts e colocá-los em sua SVN com o seu código de aplicativo para que ele vai ser implementado pelo seu mecanismo existente. Outra opção é usar o mecanismo de entrega de Nextep: scripts são exportados em algo chamado um "pacote de entrega" (scripts SQL + descritor XML), e um instalador pode entender este pacote e implantá-lo em um servidor de destino, garantindo a consistência strcutural, dependência verificar, registrar versão instalada, etc.

O produto é GPL e é baseado em Eclipse para que ele roda em Linux, Mac e Windows. Ele também suporta Oracle, MySQL e PostgreSQL no momento (suporte DB2 está a caminho). Ter um olhar para o wiki, onde você vai encontrar informações mais detalhadas: http://www.nextep-softwares.com/wiki

Respondeu 25/10/2010 em 06:46
fonte usuário

votos
9

A questão aqui é realmente o que torna fácil para os desenvolvedores criam os seus próprios alterações locais para o controle de origem para compartilhar com a equipe. Eu enfrentei este problema por muitos anos, e foi inspirado na funcionalidade do Visual Studio para profissionais de banco de dados. Se você quer uma ferramenta de código aberto com as mesmas características, tente o seguinte: http://dbsourcetools.codeplex.com/ Divirta-se, - Nathan.

Respondeu 07/07/2009 em 14:26
fonte usuário

votos
6

Scott Ambler produz uma grande série de artigos (e co-autor de um livro ) na refatoração de banco de dados, com a idéia de que você deve essencialmente aplicar os princípios e práticas de TDD para manter seu esquema. Configurar uma série de testes de unidade de dados de estrutura e de semente, para o banco de dados. Então, antes de mudar alguma coisa, você modificar / escrever testes para refletir essa mudança.

Temos vindo a fazer isso por um tempo agora e parece funcionar. Nós escrevemos código para gerar nome da coluna e tipo de dados verificações básicas em uma suíte de testes de unidade. Podemos executar novamente os testes a qualquer momento para verificar se o banco de dados no check-out SVN corresponde ao vivo db a aplicação está atualmente em execução.

Como se vê, os desenvolvedores também, por vezes, ajustar seu banco de dados caixa de areia e negligência para atualizar o arquivo de esquema no SVN. O código, em seguida, depende de uma mudança db que não foi verificado. Esse tipo de erro pode ser irritantemente difícil de definir, mas o conjunto de testes vai buscá-lo imediatamente. Isto é particularmente bom se você tê-lo construído em um plano de integração contínua maior.

Respondeu 29/08/2008 em 05:51
fonte usuário

votos
6

Despejar o seu esquema em um arquivo e adicioná-lo ao controle de origem. Em seguida, um diff simples irá mostrar-lhe o que mudou.

Respondeu 06/08/2008 em 17:59
fonte usuário

votos
5

K. Scott Allen tem um decente ou dois artigos sobre o controle de versão do esquema, que utiliza o conceito scripts de atualização incremental / migrações referenciado em outras respostas aqui; veja http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Respondeu 29/08/2008 em 06:11
fonte usuário

votos
5

Se você estiver usando C #, ter um olhar para Subsonic, uma ferramenta ORM muito útil, mas também gera script sql para recriado o seu esquema e \ ou de dados. Esses scripts podem então ser colocado em controle de origem.

http://subsonicproject.com/

Respondeu 04/08/2008 em 23:47
fonte usuário

votos
5

É meio baixa tecnologia, e pode haver uma solução melhor lá fora, mas você pode simplesmente armazenar o esquema em um script SQL que pode ser executado para criar o banco de dados. Eu acho que você pode executar um comando para gerar o script, mas eu não sei o comando infelizmente.

Em seguida, cometer o script no controle de origem, juntamente com o código que funciona com ele. Quando você precisar alterar o esquema junto com o código, o script pode ser verificada em conjunto com o código que requer o esquema alterado. Então, diffs no roteiro indicará diffs sobre as alterações do esquema.

Com este script, você pode integrá-lo com DBUnit ou algum tipo de script de construção, por isso parece que poderia se encaixar com os seus processos já automatizados.

Respondeu 04/08/2008 em 23:28
fonte usuário

votos
4

Eu usei a seguinte estrutura de projeto de banco de dados no Visual Studio para diversos projetos e funcionou muito bem:

Base de dados

Alterar Scripts

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Criar Scripts

sprocs

Funções

Visualizações

Nosso sistema de compilação, em seguida, atualiza o banco de dados de uma versão para a próxima executando os scripts na seguinte ordem:

1.PreDeploy.sql

2.SchemaChanges.sql

Índice de Criar pasta Scripts

2.DataChanges.sql

3.Permissions.sql

Cada desenvolvedor cheques em suas mudanças para um determinado bug / recurso anexando seu código para o final de cada arquivo. Uma vez que uma versão principal é completa e ramificada no controle de origem, o conteúdo dos arquivos .sql na pasta Alterar Scripts são excluídos.

Respondeu 08/08/2008 em 19:31
fonte usuário

votos
4

Usamos uma solução muito simples, mas ainda eficaz.

Para novas instalações, temos um arquivo metadata.sql no repositório que detém todo o esquema DB, então no processo de compilação que usar esse arquivo para gerar o banco de dados.

Para atualizações, nós adicionamos as atualizações no software codificado. Nós mantê-lo codificado porque nós não gostamos de resolver problemas antes que ele realmente é um problema, e esse tipo de coisa não vir a ser um problema até agora.

Portanto, no nosso software nós temos algo como isto:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Este código irá verificar se o banco de dados está na versão 1 (que é armazenado em uma tabela criada automaticamente), se ele está desatualizado, então o comando é executado.

Para atualizar o metadata.sql no repositório, corremos esse atualiza localmente e, em seguida, extrair os metadados de banco de dados completo.

A única coisa que acontece de vez em quando, é esquecer cometer o metadata.sql, mas isso não é um grande problema porque é fácil de testar no processo de construção e também a única coisa que poderia acontecer é fazer uma nova instalação com um banco de dados desatualizados e atualizado-lo na primeira utilização.

Também não apoiamos downgrades, mas é por design, se algo quebra em uma atualização, que restaurou a versão anterior e corrigir a atualização antes de tentar novamente.

Respondeu 08/08/2008 em 19:21
fonte usuário

votos
3

I criar pastas nomeadas após as versões de compilação e colocar atualizar e fazer o downgrade de scripts lá. Por exemplo, você poderia ter as seguintes pastas: 1.0.0, 1.0.1 e 1.0.2. Cada um contém o script que lhe permite atualizar ou reduzir seu banco de dados entre as versões.

Se um cliente ou um cliente chamá-lo com um problema com a versão 1.0.1 e você estiver usando 1.0.2, trazendo o banco de dados de volta para sua versão não será um problema.

Em seu banco de dados, criar uma tabela chamada "esquema" onde você coloca na versão atual do banco de dados. Em seguida, escrever um programa que pode atualizar ou reduzir seu banco de dados para você é fácil.

Assim como Joey disse, se você está em um mundo Rails, use Migrações. :)

Respondeu 05/08/2008 em 05:36
fonte usuário

votos
2

Tente db-implantação - principalmente uma ferramenta Java, mas funciona com php também.

Respondeu 19/01/2012 em 02:52
fonte usuário

votos
2

Eu gosto da maneira como Yii lida com as migrações de banco de dados. A migração é basicamente um script PHP implementação CDbMigration. CDbMigrationdefine um upmétodo que contém a lógica de migração. Também é possível implementar um downmétodo para apoiar a reversão da migração. Alternativamente, safeUpou safeDownpode ser usado para se certificar de que a migração é feita no contexto de uma transação.

Ferramenta de linha de comando do Yii yiiccontém suporte para criar e executar migrações. As migrações podem ser aplicados ou reverteu, seja um por um ou em um lote. Criando uma migração resulta em código para uma classe PHP implementação CDbMigration, exclusivamente nomeado baseado em um timestamp e um nome de migração especificado pelo usuário. Todas as migrações que foram anteriormente aplicadas ao banco de dados são armazenados em uma tabela de migração.

Para mais informações, consulte o Database Migration artigo do manual.

Respondeu 25/06/2011 em 14:18
fonte usuário

votos
2

migrações IMHO têm um enorme problema:

Atualizando de uma versão para outra funciona bem, mas fazer uma nova instalação de uma determinada versão pode demorar para sempre se você tem centenas de mesas e uma longa história de mudanças (como nós).

Correndo toda a história da deltas desde a linha de base até a versão atual (por centenas de bancos de dados de clientes) pode demorar um tempo muito longo.

Respondeu 12/03/2011 em 15:15
fonte usuário

votos
2

Toad for MySQL tem uma função chamada comparação de esquema que permite que você sincronize 2 bancos de dados. É a melhor ferramenta que tenho usado até agora.

Respondeu 05/02/2011 em 12:08
fonte usuário

votos
2

Eu recomendaria usar Ant (multiplataforma) para o lado "scripting" (uma vez que pode praticamente conversar com qualquer db lá fora via jdbc) e Subversion para o repositório de origem. Ant alow você "backup" o seu db para arquivos locais, antes de fazer alterações. 1. Backup esquema db existente para o arquivo via Ant 2. controle de versão para o repositório Subversion via Ant 3. enviar novas instruções SQL para db via Ant

Respondeu 17/09/2008 em 17:54
fonte usuário

votos
2

Para o meu projeto atual do PHP usamos a idéia de trilhos migrações e nós temos um diretório migrações em que podemos manter arquivos título "migration_XX.sql", onde XX é o número da migração. Atualmente, esses arquivos são criados à mão como as atualizações são feitas, mas a sua criação poderia ser facilmente modificado.

Então nós temos um script chamado "Migration_watcher", que, como estamos na pré-alpha, atualmente roda em cada carregamento da página e verifica se há um novo arquivo migration_XX.sql onde XX é maior do que a versão de migração atual. Se assim for, corre todos os arquivos migration_XX.sql-se ao maior número contra o banco de dados e voila! alterações de esquema são automatizados.

Se você precisar a capacidade de reverter o sistema exigiria um monte de ajustes, mas é simples e tem vindo a trabalhar muito bem para a nossa bastante pequena equipe até agora.

Respondeu 23/08/2008 em 13:58
fonte usuário

votos
0

Há uma linha de comando mysql-diff ferramenta que compara os esquemas de banco de dados, onde esquema pode ser um banco de dados ao vivo ou script SQL no disco. É bom para a maioria das tarefas de migração de esquema.

Respondeu 04/11/2009 em 20:43
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more