Controle de versão com SQL Server

Estou iniciando um novo projeto e usando o SVN (com o Tortoise) como meu sistema de controle de versão. Eu queria saber se era possível também manter um banco de dados SQL Server usando o mesmo sistema.

Eu gostaria de versão minhas tabelas / funções / visualizações / procs / triggers / etc. mas não os meus dados, pois todos serão dados de teste de qualquer maneira. Não tenho muita certeza de como configurar isso. Encontrei algumas opções, mas gostaria de saber se havia alguma que estivesse faltando, e se há algum guia ou algo lá fora para me ajudar a continuar com ela.

Eu já vi e ouvi falar do Red Gate, mas estou procurando algo gratuito (ou pelo menos, muito baixo custo). Eu sei que sempre poderia escrever algo sozinho, mas não estou tentando gastar tempo nisso.

Uma coisa que encontrei foi um pacote de código aberto chamado ScriptDB4Svn . Alguém usou isso antes? Isso é bom? Ele pode fazer as coisas que eu preciso e é bem simples de configurar?

Tecnicamente, você nem precisa de uma ferramenta, pode script os objetos diretamente e verificá-los no controle de origem. É um pouco mais de trabalho sem a ferramenta, mas é definitivamente viável.

BTW: Eu usei a ferramenta RedGate e é muito lisa e vale o dinheiro.

Parece que você tem uma configuração principalmente da Microsoft. Você pode dar uma olhada em Projetos de banco de dados (anteriormente conhecido como DataDude). Eles basicamente transformam o T-SQL em uma linguagem de primeira classe no Visual Studio; você pode:

• Compilar projetos - ele não cria apenas um script final, garante que os nomes de objetos etc. existam.
• Execute a análise estática do código - por exemplo, garantindo que você sempre se refira aos objetos, incluindo o esquema (por exemplo, [dbo]na maioria dos casos) para obter um ótimo aumento de 30% no desempenho.
• Crie scripts diff, comparando diferentes versões do projeto.
• Atualize seu projeto a partir de um banco de dados ou script (engenharia reversa).
• Intellisense.
• Não há ferramentas de diagramação.

Eles unificam seu código e o código do banco de dados também sob controle de origem. Se você criar e criar scripts para seus objetos de banco de dados (em vez de usar o Davinci Tools no SSMS), também usará um IDE - o que é bom.

Você pode usar o Rails. O Rails tem um conceito de migração de banco de dados que você pode aplicar ou reverter. Na minha experiência, esta é a melhor maneira de versão de um banco de dados. Você verifica esses arquivos de migração no SVN.

No meu projeto atual, não estamos desenvolvendo o aplicativo em Ruby, mas ainda estamos usando o Rails para gerenciar o banco de dados. Eu não faria isso de outra maneira.

Isso foi discutido anteriormente no stackoverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Além disso, este artigo externo fornece algumas informações adicionais http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated junto com o código de exemplo na forma de um aplicativo do Windows.

Como o que você quer fazer é algo que eu mesmo fiz para o MS Access, vou lhe contar o que fiz caso isso lhe dê algumas idéias: escrevi um módulo chamado Ado2Xml que converte o esquema e os dados de qualquer ADO banco de dados acessível para xml e vice-versa. Porém, ele conhece apenas tabelas e visualizações; sem procedimentos armazenados, sem gatilhos, sem nada. De qualquer forma, no seu caso, este módulo é substituído pela ferramenta que você provavelmente encontrará o que deseja com o MS-SQL. Portanto, toda vez que meu aplicativo é iniciado, ele compara o registro de data e hora do banco de dados com o registro de data e hora do arquivo xml salvo; se o arquivo xml for mais recente, ele destrói o banco de dados e chama o Ado2Xml para recriá-lo a partir do arquivo xml. Quando meu aplicativo termina, ele faz o inverso: ele invoca o Ado2Xml para exportar o banco de dados para o arquivo xml. Na realidade, por algum motivo, os objetos ADO que extraem o esquema do banco de dados são muito lentos, fazendo com que o processo de exportação demore algum tempo. Portanto, para evitar ter que esperar cada vez que meu aplicativo seja finalizado e o visual studio alternar do layout de depuração para o layout de edição, logo antes de terminar, meu aplicativo inicia um aplicativo externo para exportar, para que ele possa finalizar imediatamente.

Sim, usei uma ferramenta semelhante (desenvolvida internamente) em um projeto anterior. Ele script todas as tabelas, visualizações, sprocs, gatilhos, etc em arquivos .sql individuais. Em seguida, tínhamos um script executado todas as noites para "validar" que tudo em nosso banco de dados de "desenvolvimento" se refletia no controle de origem.

Portanto, o fluxo de trabalho normal é que você altera seu código, altera as tabelas e sprocs correspondentes no banco de dados de desenvolvimento, conforme necessário, e executa a ferramenta que possuímos, que atualiza todos os arquivos .sql com script. Você então verifica tudo de uma vez.

O problema era que, se você esquecesse de executar a ferramenta, o código "funcionaria" (e os testes de unidade passariam) porque o banco de dados estava "correto", mas os novos sprocs / tabelas não seriam o controle de origem.

Então, todas as noites, temos um script que faz o check-out do código-fonte e, em seguida, reúne a ferramenta para atualizar todos os scripts. Se houver alguma diferença, significa que alguém esqueceu de fazer o check-in de suas alterações e uma notificação por email foi gerada. Era basicamente apenas uma maneira de garantir que não esquecessemos de manter o controle da fonte atualizado.

Foi um pouco chato porque dificultava o trabalho de alterações que duravam vários dias, mas era melhor do que não ter nada ...