sql-server - studio - sql server source control tools




Banco de dados de versão do SQL Server (20)

É simples.

  1. Quando o projeto base estiver pronto, você deverá criar um script completo do banco de dados. Este script foi confirmado no SVN. É a primeira versão.

  2. Depois disso, todos os desenvolvedores criam scripts de alteração (ALTER ..., novas tabelas, sprocs, etc).

  3. Quando você precisar da versão atual, execute todos os novos scripts de alteração.

  4. Quando o aplicativo é lançado para produção, você volta para 1 (mas será a versão sucessiva, é claro).

Nant ajudará você a executar esses scripts de alteração. :)

E lembre-se. Tudo funciona bem quando há disciplina. Sempre que a alteração do banco de dados é confirmada, as funções correspondentes no código também são confirmadas.

Quero colocar meus bancos de dados sob controle de versão. Alguém tem algum conselho ou artigos recomendados para começar?

Eu sempre vou querer ter pelo menos alguns dados lá (como menciona alumb : tipos de usuários e administradores). Também desejarei muitas vezes uma grande coleção de dados de teste gerados para medições de desempenho.


É uma boa abordagem salvar os scripts do banco de dados no controle de versão com os scripts de alteração, para que você possa atualizar qualquer banco de dados existente. Além disso, convém salvar esquemas para versões diferentes, para poder criar um banco de dados completo sem a necessidade de aplicar todos os scripts de alteração. O tratamento dos scripts deve ser automatizado para que você não precise fazer trabalho manual.

Eu acho que é importante ter um banco de dados separado para cada desenvolvedor e não usar um banco de dados compartilhado. Dessa forma, os desenvolvedores podem criar casos de teste e fases de desenvolvimento independentemente de outros desenvolvedores.

A ferramenta de automação deve ter meios para lidar com os metadados do banco de dados, que informa quais bancos de dados estão em que estado de desenvolvimento e quais tabelas contêm dados controláveis ​​por versão e assim por diante.


+1 para todos os que recomendaram as ferramentas RedGate, com uma recomendação adicional e uma ressalva.

O SqlCompare também possui uma API decentemente documentada: para que você possa, por exemplo, escrever um aplicativo de console que sincronize sua pasta de scripts controlados de origem com um banco de dados de teste de integração de IC no check-in, para que quando alguém fizer check-in de uma alteração no esquema da pasta de scripts é implantado automaticamente junto com a alteração do código do aplicativo correspondente. Isso ajuda a fechar a lacuna com os desenvolvedores que esquecem a propagação de alterações em seu banco de dados local até um banco de dados de desenvolvimento compartilhado (cerca de metade de nós, acho :)).

Uma ressalva é que, com uma solução com script ou de outra forma, as ferramentas RedGate são suficientemente suaves para facilitar o esquecimento das realidades SQL subjacentes à abstração. Se você renomear todas as colunas em uma tabela, o SqlCompare não poderá mapear as colunas antigas para as novas e eliminará todos os dados da tabela. Isso irá gerar avisos, mas já vi pessoas clicarem além disso. Acho que vale a pena ressaltar que você só pode automatizar o versionamento e a atualização do DB até agora - as abstrações são muito vazadas.


A solução típica é despejar o banco de dados conforme necessário e fazer backup desses arquivos.

Dependendo da sua plataforma de desenvolvimento, pode haver plugins de código aberto disponíveis. Rolar seu próprio código para fazer isso geralmente é bastante trivial.

Nota: convém fazer backup do dump do banco de dados em vez de colocá-lo no controle de versão. Os arquivos podem ficar enormes rapidamente no controle de versão e fazer com que todo o sistema de controle de fonte fique lento (estou relembrando uma história de horror do CVS no momento).


Com o VS 2010, use o projeto Banco de Dados.

  1. Script seu banco de dados
  2. Faça alterações nos scripts ou diretamente no servidor db
  3. Sincronize usando Dados> Comparação de esquemas

Cria uma solução perfeita de controle de versão de banco de dados e facilita a sincronização de bancos de dados.


Começamos a usar o Team Foundation Server. Se o seu banco de dados é de tamanho médio, o Visual Studio possui algumas integrações interessantes de projeto com comparação, comparação de dados, ferramentas de refatoração de banco de dados, estrutura de teste de banco de dados e até ferramentas de geração de dados.

Mas, esse modelo não se encaixa muito bem em bancos de dados grandes ou de terceiros (que criptografam objetos) muito bem. Então, o que fizemos é armazenar apenas nossos objetos personalizados. O servidor de base do Visual Studio / Team funciona muito bem para isso.

Arco principal do banco de dados TFS. blogue

Site MS TFS


Concordo com a resposta ESV e, por esse motivo exato, iniciei um pequeno projeto há algum tempo para ajudar a manter as atualizações do banco de dados em um arquivo muito simples, que poderia ser mantido com um código-fonte de lado longo. Ele permite atualizações fáceis para desenvolvedores, bem como UAT e produção. A ferramenta funciona, mas o Sql Server e o MySql.

Alguns recursos do projeto:

  • Permite alterações de esquema
  • Permite população de árvores de valor
  • Permite inserções de dados de teste separadas, por exemplo. UAT
  • Permite a opção de reversão (não automatizada)
  • Mantém suporte para SQL server e Mysql
  • Tem a capacidade de importar seu banco de dados existente para o controle de versão com um comando simples (apenas servidor sql ... ainda trabalhando no mysql)

O código está hospedado no código do Google. Confira o código do Google para obter mais informações

http://code.google.com/p/databaseversioncontrol/


Confira DBGhost DBGhost . Eu uso de forma automatizada há 2 anos e funciona muito bem. Ele permite que nossas compilações de banco de dados aconteçam da mesma forma que uma compilação Java ou C, exceto o banco de dados. Você sabe o que eu quero dizer.


Eu escrevi este aplicativo há um tempo atrás, http://sqlschemasourcectrl.codeplex.com/ , que varrerá os seus bancos de dados MSFT SQL quantas vezes quiser e despejará automaticamente seus objetos (tabelas, visualizações, procs, funções, configurações sql) no SVN. Funciona como um encanto. Eu o uso com o Unfuddle (o que me permite receber alertas nos check-ins)


Eu sugeriria o uso de ferramentas de comparação para improvisar um sistema de controle de versão para o seu banco de dados. Uma boa alternativa são o xSQL Schema Compare e o xSQL Data Compare .

Agora, se seu objetivo é ter apenas o esquema do banco de dados sob controle de versão, você pode simplesmente usar xSQL Schema Compare para gerar xSQL Snapshots do esquema e adicionar esses arquivos ao seu controle de versão. Para reverter ou atualizar para uma versão específica, basta comparar a versão atual do banco de dados com a captura instantânea da versão de destino.

Infelizmente, se você também deseja que os dados estejam sob controle de versão, é possível usar o xSQL Data Compare para gerar scripts de alteração para o banco de dados e adicionar os arquivos .sql ao controle de versão. Você pode então executar esses scripts para reverter / atualizar para qualquer versão que desejar. Lembre-se de que, para a funcionalidade 'reverter', é necessário gerar scripts de alteração que, quando executados, tornarão a Versão 3 igual à Versão 2 e, para a funcionalidade 'atualizar', será necessário gerar scripts de alteração que fazem o contrário.

Por fim, com algumas habilidades básicas de programação em lote, você pode automatizar todo o processo usando as versões de linha de comando do xSQL Schema Compare e xSQL Data Compare

Isenção de responsabilidade: sou afiliado ao xSQL.


Martin Fowler escreveu meu artigo favorito sobre o assunto, http://martinfowler.com/articles/evodb.html . Eu escolho não colocar despejos de esquema no controle de versão, como sugerido por outros, porque eu quero uma maneira fácil de atualizar meu banco de dados de produção.

Para um aplicativo Web em que terei uma única instância de banco de dados de produção, utilizo duas técnicas:

Scripts de atualização do banco de dados

Scripts de atualização de banco de dados de sequência que contêm o DDL necessário para mover o esquema da versão N para N + 1. (Elas estão no seu sistema de controle de versão.) Uma tabela _version_history_, algo como

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

recebe uma nova entrada sempre que um script de atualização é executado, o que corresponde à nova versão.

Isso garante que seja fácil ver qual versão do esquema do banco de dados existe e que os scripts de atualização do banco de dados sejam executados apenas uma vez. Novamente, esses não são despejos de banco de dados. Em vez disso, cada script representa as alterações necessárias para passar de uma versão para a seguinte. Eles são o script que você aplica ao seu banco de dados de produção para "atualizá-lo".

Sincronização de sandbox do desenvolvedor

  1. Um script para fazer backup, higienizar e reduzir um banco de dados de produção. Execute isso após cada atualização no banco de dados de produção.
  2. Um script para restaurar (e ajustar, se necessário) o backup na estação de trabalho de um desenvolvedor. Cada desenvolvedor executa esse script após cada atualização no banco de dados de produção.

Uma ressalva: meus testes automatizados são executados em um banco de dados vazio, mas com correção de esquema, portanto, este conselho não atenderá perfeitamente às suas necessidades.


Não armazenamos o esquema do banco de dados, armazenamos as alterações no banco de dados. O que fazemos é armazenar as alterações no esquema para criar um script de mudança para qualquer versão do banco de dados e aplicá-lo aos bancos de dados de nossos clientes. Eu escrevi um aplicativo utilitário de banco de dados que é distribuído com o aplicativo principal que pode ler esse script e saber quais atualizações precisam ser aplicadas. Ele também possui inteligência suficiente para atualizar visualizações e procedimentos armazenados, conforme necessário.


O produto SQL Compare do Red Gate não apenas permite que você faça comparações no nível de objeto e gere scripts de alteração a partir disso, mas também permite exportar seus objetos de banco de dados para uma hierarquia de pastas organizada por tipo de objeto, com uma criação [nome do objeto] .sql script por objeto nesses diretórios. A hierarquia do tipo de objeto é assim:

\Funções
\Segurança
\ Segurança \ Funções
\ Security \ Schemas
\ Segurança \ Usuários
\Procedimentos armazenados
\ Tables

Se você despejar seus scripts no mesmo diretório raiz depois de fazer alterações, poderá usá-lo para atualizar seu repositório SVN e manter um histórico de execução de cada objeto individualmente.


Para tornar o despejo em um sistema de controle de código-fonte um pouco mais rápido, você pode ver quais objetos foram alterados desde a última vez, usando as informações da versão em sysobjects.

Configuração: crie uma tabela em cada banco de dados que você deseja verificar incrementalmente para reter as informações da versão da última vez que você as verificou (vazia na primeira execução). Limpe esta tabela se desejar verificar novamente toda a estrutura de dados.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Modo de execução normal: você pode pegar os resultados desse sql e gerar scripts sql apenas para os interessados, e colocá-los no controle de origem de sua escolha.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Nota: Se você usar um agrupamento não padrão em qualquer um dos seus bancos de dados, será necessário substituir /* COLLATE */ pelo agrupamento do banco de dados. ie COLLATE Latin1_General_CI_AI


Se você possui um banco de dados pequeno e deseja fazer a versão completa, esse script em lote pode ajudar. Ele desanexa, compacta e verifica um arquivo MDF do banco de dados MSSQL no Subversion.

Se você deseja versão do seu esquema e apenas possui uma pequena quantidade de dados de referência, é possível usar as Migrações SubSonic para lidar com isso. O benefício é que você pode migrar facilmente para cima ou para baixo para qualquer versão específica.


Também estou usando uma versão no banco de dados armazenada por meio da família de procedimentos de propriedades estendidas do banco de dados. Meu aplicativo possui scripts para cada etapa da versão (ou seja, passe de 1.1 para 1.2). Quando implantado, ele analisa a versão atual e executa os scripts um por um até chegar à última versão do aplicativo. Não existe um script que tenha a versão "final" direta, mesmo que implemente em um banco de dados limpo a implante por meio de uma série de etapas de atualização.

Agora, o que eu gostaria de acrescentar é que eu vi dois dias atrás uma apresentação no campus da MS sobre a nova e futura edição do VS DB. A apresentação foi focada especificamente neste tópico e fiquei impressionado. Você deve definitivamente conferir, as novas instalações estão focadas em manter a definição de esquema nos scripts T-SQL (CREATEs), um mecanismo delta de tempo de execução para comparar o esquema de implantação com o esquema definido e executar os ALTERs delta e integração com a integração do código-fonte, até e incluindo a integração contínua MSBUILD para quedas automatizadas de compilação. A gota conterá um novo tipo de arquivo, os arquivos .dbschema, que podem ser levados ao site de implantação e uma ferramenta de linha de comando pode executar os 'deltas' reais e executar a implantação. Eu tenho uma entrada de blog sobre esse tópico com links para os downloads do VSDE; você deve vê-los: http://rusanu.com/2009/05/15/version-control-and-your-database/


Todo banco de dados deve estar sob controle de código-fonte. O que falta é uma ferramenta para script automaticamente todos os objetos de banco de dados - e "dados de configuração" - em arquivo, que podem ser adicionados a qualquer sistema de controle de origem. Se você estiver usando o SQL Server, minha solução está aqui: http://dbsourcetools.codeplex.com/ . Diverta-se. Nathan.


Usamos o DBGhost para gerenciar nosso banco de dados SQL. Em seguida, você coloca seus scripts para criar um novo banco de dados em seu controle de versão e ele cria um novo banco de dados ou atualiza qualquer banco de dados existente para o esquema no controle de versão. Dessa forma, você não precisa se preocupar em criar scripts de alteração (embora você ainda possa fazer isso, se, por exemplo, quiser alterar o tipo de dados de uma coluna e precisar converter dados).


Você pode querer consultar o Liquibase ( http://www.liquibase.org/ ). Mesmo que você não use a ferramenta, ela lida com os conceitos de gerenciamento de alterações ou refatoração de banco de dados muito bem.


Você também pode procurar uma solução de migração. Isso permite que você especifique o esquema do banco de dados no código C # e role a versão do banco de dados para cima e para baixo usando o MSBuild.

Atualmente, estou usando o DbUp e está funcionando bem.





version-control