Pergunta

Alguém pode fornecer alguns exemplos reais sobre a melhor forma de manter arquivos de script para visualizações, procedimentos armazenados e funções em um repositório SVN (ou outro).

Obviamente, uma solução é ter os arquivos de script para todos os diferentes componentes em um diretório ou mais em algum lugar e simplesmente usar o TortoiseSVN ou algo semelhante para mantê-los no SVN. Então, sempre que for necessária uma alteração, eu carrego o script no Management Studio, etc. .Eu realmente não quero isso.

O que eu realmente prefiro é algum tipo de script em lote que eu possa executar periodicamente (todas as noites?) Que exporte todos os procedimentos/visualizações armazenados, etc., que foram alterados em um determinado período de tempo e depois os confirme no SVN.

Ideias?

Foi útil?

Solução

Parece que você não quer usar o Controle de Revisão corretamente, para mim.

Obviamente, uma solução é ter os arquivos de script para todos os diferentes componentes em um diretório ou mais em algum lugar e simplesmente usar o Tortoisesvn ou o gosto de mantê -los em svn

Isto é o que deveria ser feito.Você teria sua cópia local na qual está trabalhando (Desenvolvendo novos, Ajustando antigos, etc.) e à medida que componentes/procedimentos/etc únicos fossem concluídos, você os submeteria individualmente até ter que reiniciar o processo.

Comprometer código incompleto só porque já faz 'X' tempo desde que foi confirmado pela última vez é desleixado e certamente causará sofrimento a qualquer outra pessoa que use o repositório.

Outras dicas

Acho melhor tratar os procedimentos armazenados como qualquer outro código compilável:O código fica no repositório, você faz check-out para fazer alterações e carrega-o em sua ferramenta de desenvolvimento para compilar ou implantar o código.

Você pode criar um arquivo em lote e agendá-lo:

  • exclua o conteúdo do seu diretório de scripts
  • usando algo como ExportarSQLScript para exportar todos os objetos para script/scripts
  • svn commit

Observe:Embora você tenha os objetos sob controle de origem, não terá os dados ou sua progressão (é um campo renomeado ou 1 campo novo e 1 excluído?).

Essa abordagem é adequada para manter o histórico de alterações.Mas, é claro, você nunca deve se comprometer automaticamente com a "compilação de produção" (a menos que goste de compilações quebradas).

Embora você não tenha pedido por isso:Essa abordagem também não produzirá um conjunto de scripts que atualizará um banco de dados atual.Você terá apenas scripts de criação inicial.A gravação da progressão de dados e a criação de scripts de atualização estão além dos sistemas básicos de controle de origem.

eu recomendaria Redgate SQL Compare para isso - permite comparar versões de banco de dados e gerar scripts de alteração - também é facilmente programável.

Com base na sua pergunta expandida, você realmente deseja usar gatilhos DDL.Confira Este artigo que detalha como criar um sistema de changelog para seu banco de dados.

Não tenho certeza sobre sua faixa de preço, no entanto Banco de Dados Fantasma pode ser uma opção para você.

Não trabalho para esta empresa (nem possuo o produto), mas em minhas pesquisas sobre o mesmo problema, este produto parecia bastante promissor.

Eu deveria ter sido um pouco mais descritivo.O banco de dados em questão é para um sistema ERP interno e por isso não temos muitas versões do nosso banco de dados, apenas Produção/Testes/Desenvolvimento.Quando fazemos uma solicitação de mudança, algum novo recurso sofisticado ou algo assim, simplesmente executamos um script ou uma série de scripts para atualizar os procedimentos em questão no banco de dados de Teste, se estiver tudo bem, fazemos o mesmo com a Produção.

Portanto, não estou realmente atrás de um script de esquema completo, apenas algo que possa acompanhar as várias edições nos procedimentos armazenados ao longo do tempo.Por exemplo, PROCESS_INVOICE faz coisas.Ele é atualizado de alguma forma em março.Algum tempo depois, em maio, descobriu-se que, em um caso raro, os clientes recebem faturas duplas (ou algum outro caso maluco).Gostaria de poder ver o que aconteceu ao longo do tempo com esse procedimento.Atualmente a forma como o ambiente de desenvolvimento está configurado aqui não tenho isso, o que estou tentando mudar.

Posso recomendar o DBPro, que faz parte do Visual Studio Team Edition.Estou usando-o há alguns meses para armazenar todas as partes do banco de dados no Team Foundation Server, bem como para implantação e comparação de bancos de dados, etc.

Claro, como alguém mencionou, isso depende do seu ambiente e faixa de preço.

Eu escrevi um utilitário para despejar todas as partes relevantes do meu banco de dados em uma estrutura de diretórios na qual uso o SVN.Nunca tentei incorporá-lo ao Manager, mas, se você estiver interessado, está aqui: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

É gratuito e, como eu o executo regularmente, você sabe que qualquer bug é corrigido rapidamente.

Você sempre pode tentar integrar o SourceSafe ao SQL Server.Aqui está um começo rápido: link .Para trabalhar com isso você precisa ter o Management Studio Developers Edition.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top