Como você acompanhar as alterações de banco de dados no controle de origem?

votos
22

Nós usamos o SQL Server 2000/2005 e Vault ou SVN na maioria dos nossos projetos. Eu não encontrei uma solução decente para capturar alterações de banco de dados esquema / proc em qualquer sistema de controle de origem.

Nossa solução atual é bastante complicado e difícil de aplicar (script de fora do objeto que você alterar e comprometer-lo para o banco de dados).

Temos um monte de idéias de como resolver este problema com algum desenvolvimento personalizado, mas eu prefiro instalar uma ferramenta existente (ferramentas pagas são muito bem).

Então: como você controla as alterações de código de banco de dados? Você tem ferramentas recomendadas?


Editar:

Obrigado por todas as sugestões. Devido a limitações de tempo, eu prefiro não fazer a minha própria aqui. E a maioria das sugestões têm a falha que eles exigem o dev de seguir algum procedimento.

Em vez disso, a solução ideal seria monitorar o banco de dados SQL para mudanças e comprometer quaisquer alterações detectadas ao SCM. Por exemplo, se SQL Server teve um add-on que poderia gravar qualquer alteração DML com o usuário que fez a alteração, em seguida, cometer o script desse objeto para SCM, eu ficaria emocionado.

Nós conversamos internamente cerca de dois sistemas: 1. No SQL 2005, use permissões de objeto para restringi-lo de alterar um objeto até que fez um check-out. Em seguida, o procedimento de check-in seria roteiro lo para o SCM. 2. Execute um trabalho agendado para detectar quaisquer alterações e cometê-los (anonimamente) para SCM.

Seria bom se eu pudesse pular a parte do usuário de ação e têm o sistema de lidar com tudo isso automaticamente.

Publicado 09/12/2008 em 14:57
fonte usuário
Em outras línguas...                            


14 respostas

votos
3

solução de um pobre homem seria adicionar um commit pré-script de gancho que despeja o mais recente esquema db em um arquivo e tem esse arquivo comprometida com seu repositório SVN, juntamente com o seu código. Depois, você pode diff os arquivos de esquema db de qualquer revisão.

Respondeu 09/12/2008 em 15:01
fonte usuário

votos
1

Eu só comprometer o SQL-alter-Declaração adicional para o SQL-CreateDB-declaração completa.

Respondeu 09/12/2008 em 15:01
fonte usuário

votos
1

Aqui está Jeff Atwood sobre Get Your banco de dados sob controle de versão .

Respondeu 09/12/2008 em 15:03
fonte usuário

votos
15

Use edição Visual banco de dados estúdio para roteiro em seu banco de dados. Funciona como um encanto e você pode usar qualquer sistema de controle de origem, é claro melhor se ele tem plugins VS. Esta ferramenta tem também uma série de outras funcionalidades úteis. Vê-los aqui neste grande post

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

ou check-out MSDN para a documentação oficial

Respondeu 09/12/2008 em 15:03
fonte usuário

votos
1

Em SQL2000 gerar cada objeto em seu próprio arquivo , em seguida, verificar-los todos em seu controle de origem. Deixe o seu controle de origem lidar com o histórico de alterações.

No SQL 2005, você precisa escrever um pouco de código para gerar todos os objetos em arquivos separados.

Respondeu 09/12/2008 em 15:04
fonte usuário

votos
5

Eu tenho que dizer que eu acho que um projeto de banco de dados visual studio também é uma solução razoável para o dilema de controle de origem. Se ele está configurado corretamente, você pode executar os scripts no banco de dados do IDE. Se o seu roteiro é velho, obter o mais recente, executá-lo contra o DB. Ter um script que recria todos os objetos, bem como se você precisa, novos objetos devem ser adicionados à este script bem à mão, mas apenas uma vez

Eu gosto de cada mesa, proc e função para estar em seu próprio arquivo.

Respondeu 09/12/2008 em 15:19
fonte usuário

votos
0

Nossos DBAs verificar periodicamente prod contra o que está no SVN e excluir quaisquer objetos que não estão sob controle de origem. Leva apenas uma vez antes de os devlopers nunca se esqueça de colocar algo no controle de origem novamente.

Nós também não permitem que qualquer pessoa para mover objetos para prod sem um script como nossos devs não têm direito a prod isso é fácil de aplicar.

Respondeu 09/12/2008 em 15:31
fonte usuário

votos
1

Rolling seu próprio a partir do zero não seria muito factível, mas se você usar uma ferramenta de comparação de sql como Redgate SQL Compare SDK para gerar seus arquivos de mudança para você que não iria demorar muito tempo para meia-roll que você quer e, em seguida, basta verificar esses arquivos para controlo de origem. Rolei algo semelhante para me atualizar alterações de nossos sistemas de desenvolvimento para os nossos sistemas vivos, em apenas algumas horas.

Respondeu 09/12/2008 em 15:34
fonte usuário

votos
1

Em nosso meio, nós nunca mudar o DB manualmente: todas as alterações são feitas por scripts em tempo de liberação, e os scripts são mantidos no sistema de controle de versão. Uma parte importante deste processo é ter a certeza de que todos os scripts podem ser executados novamente contra o mesmo DB os scripts são idempotentes?) Sem perda de dados. Por exemplo, se você adicionar uma coluna, certifique-se que você não faz nada se a coluna já está lá.

O seu comentário sobre "sugestões têm a falha que eles exigem o dev de seguir algum procedimento" é realmente um diga-conto. Não é um defeito, é uma característica. O controle de versão ajuda os desenvolvedores em procedimentos seguintes e faz os procedimentos menos dolorosos. Se você não quer seguir os procedimentos, você não precisa de controle de versão.

Respondeu 09/12/2008 em 17:32
fonte usuário

votos
0

Em um projeto que eu organizados por cuidadosa atenção na concepção de que todos os dados importantes no banco de dados pode ser recriado automaticamente a partir de locais externos. Ao iniciar, o aplicativo cria o banco de dados se ele estiver ausente, e preenche-lo a partir de fontes externas de dados, utilizando um esquema no código fonte da aplicação (e, portanto, controle de versão com a aplicação). O nome da loja de banco de dados (um nome de arquivo SQLite, embora a maioria dos gerentes de banco de dados permitem que várias bases de dados) inclui uma versão do esquema, e nós aumentamos a versão do esquema sempre que cometer uma alteração de esquema. Isto significa que quando reiniciar o aplicativo para uma nova versão com um esquema diferente que uma nova loja de banco de dados é automaticamente criado e preenchido. Devemos ter para reverter a implantação de um esquema de idade, em seguida, a nova execução da versão antiga será usando o armazenamento de banco de dados de idade,

Essencialmente, o banco de dados age como um heap do aplicativo tradicional, com as vantagens de persistência, segurança de transação, tipagem estática (útil desde que usar Python) e as restrições de exclusividade. No entanto, não se preocupar em tudo sobre a exclusão de banco de dados e começar de novo, e as pessoas sabem que se tentarem algum hack manual no banco de dados, em seguida, ele vai ter revertido na próxima implantação, bem como hacks de um estado processo vai se reverteu na próxima reinicialização.

Nós não precisamos de quaisquer scripts de migração, uma vez que basta mudar nome de arquivo de banco de dados e reiniciar o aplicativo e se reconstrói. Ela ajuda a que as instâncias do aplicativo são sharded usar um banco de dados por cliente. Ele também reduz a necessidade de backups de banco de dados.

Esta abordagem não vai funcionar se a sua construção de banco de dados a partir de fontes externas leva mais tempo do que você vai permitir que o aplicativo seja permanecer baixo.

Respondeu 15/12/2008 em 14:14
fonte usuário

votos
0

Se você estiver usando Net e como os Rails abordagem leva com as migrações, então eu recomendo Migrator.Net .

Eu encontrei um bom tutorial que anda através de configurá-lo no Visual Studio. Ele também fornece um projeto de amostra para fazer referência.

Respondeu 18/09/2009 em 19:03
fonte usuário

votos
0

Nós desenvolvemos uma ferramenta personalizada que atualiza nossa base de dados. O esquema de banco de dados é armazenado em um arquivo XML banco de dados neutra que é então lido e processado pela ferramenta. O esquema fica armazenado no SVN, e nós adicionar comentários apropriado para mostrar o que foi alterado. Ele funciona muito bem para nós.

Embora este tipo de solução é definitivamente um exagero para a maioria dos projetos, que certamente facilita a vida às vezes.

Respondeu 18/09/2009 em 19:15
fonte usuário

votos
0

Para acompanhar todas as mudanças como atualização inserção e exclusão haverá muita sobrecarga para o SVN. É melhor para rastrear apenas as alterações DDL como (alter, drop, criar) que muda o esquema. Você pode fazer isso esquema de rastreamento facilmente através da criação de uma mesa e uma trgger para inserir dados a essa tabela. Toda vez que você quiser u pode obter o status de alteração por meio de consulta dessa tabela Há um monte de exemplo aqui e aqui

Respondeu 26/06/2012 em 16:02
fonte usuário

votos
5

O rastreamento de alterações de banco de dados diretamente do SSMS é possível usando várias ferramentas 3rd party. Controle Fonte ApexSQL roteiros automaticamente qualquer objeto de banco de dados que está incluído na versão. Compromete não pode ser executada automaticamente pela ferramenta. Em vez disso, o usuário precisa escolher quais mudanças serão comprometidos.

Ao obter as alterações de um repositório, Controle de origem ApexSQL está ciente de uma integridade referencial do banco de dados SQL. Assim, ele irá criar um script de sincronização, incluindo todos os objetos dependentes que serão envolvidos em uma transação assim, inclua todas as alterações serão aplicadas no caso de nenhum erro for encontrado, ou nenhuma das alterações selecionadas é aplicada. Em qualquer caso, a integridade do banco de dados permanece inalterado.

Respondeu 07/12/2017 em 15:12
fonte usuário

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