Versionamento do banco de dados SQL Server

08-06-2019
|

Pergunta

Quero colocar meus bancos de dados sob controle de versão.Alguém tem algum conselho ou artigo recomendado para me ajudar a começar?

Eu sempre vou querer ter pelo menos alguns dados lá (como alume menciona:tipos de usuários e administradores).Freqüentemente, também desejarei uma grande coleção de dados de teste gerados para medições de desempenho.

Solução

Martin Fowler escreveu meu artigo favorito sobre o assunto, http://martinfowler.com/articles/evodb.html.Eu escolho não colocar dumps de esquema sob controle de versão, pois alume e outros sugerem porque quero uma maneira fácil de atualizar meu banco de dados de produção.

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

Scripts de atualização de banco de dados

Uma sequência de scripts de atualização de banco de dados que contém o DDL necessário para mover o esquema da versão N para N+1.(Eles vão para o 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
    );

obtém 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, estes são não despejos de banco de dados.Em vez disso, cada script representa o mudanças necessário passar de uma versão para outra.Eles são o script que você aplica ao seu banco de dados de produção para “atualizá-lo”.

Sincronização do Sandbox do Desenvolvedor

Um script para fazer backup, limpar e reduzir um banco de dados de produção.Execute isso após cada atualização para o banco de dados de produção.
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 advertência:Meus testes automatizados são executados em um banco de dados com esquema correto, mas vazio, portanto, este conselho não atenderá perfeitamente às suas necessidades.

Outras dicas

O produto SQL Compare da Red Gate não apenas permite que você faça comparações em 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 de tipo de objeto é assim:

\Funções
\Segurança
\Segurança\Funções
\Segurança\Esquemas
\Segurança\Usuários
\Procedimentos armazenados
abelas

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

Este é um dos “problemas difíceis” que rodeiam o desenvolvimento.Pelo que sei não existem soluções perfeitas.

Se você precisar apenas armazenar a estrutura do banco de dados e não os dados, poderá exportar o banco de dados como consultas SQL.(no Gerenciador Empresarial:Clique com o botão direito no banco de dados -> Gerar script SQL.Eu recomendo definir "criar um arquivo por objeto" na guia de opções. Você pode então enviar esses arquivos de texto para o svn e usar as funções diff e logging do svn.

Eu tenho isso vinculado a um script em lote que usa alguns parâmetros e configura o banco de dados.Também adicionei algumas consultas adicionais que inserem dados padrão, como tipos de usuários e o usuário administrador.(Se você quiser mais informações sobre isso, poste algo e posso colocar o script em algum lugar acessível)

Se você também precisar manter todos os dados, recomendo manter um backup do banco de dados e usar Redgate (http://www.red-gate.com/) produtos para fazer as comparações.Eles não são baratos, mas valem cada centavo.

Primeiro, você deve escolher o sistema de controle de versão certo para você:

Sistema centralizado de controle de versão - um sistema padrão onde os usuários fazem check-out/check-in antes/depois de trabalhar nos arquivos, e os arquivos são mantidos em um único servidor central
Sistema de controle de versão distribuída - um sistema em que o repositório está sendo clonado e cada clone é na verdade o backup completo do repositório; portanto, se algum servidor travar, qualquer repositório clonado pode ser usado para restaurá -lo depois de escolher o sistema certo para suas necessidades , você precisará configurar o repositório, que é o núcleo de cada sistema de controle de versão, tudo isso é explicado no artigo a seguir: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/

Depois de configurar um repositório, e no caso de um sistema central de controle de versão uma pasta de trabalho, você pode ler Este artigo.Ele mostra como configurar o controle de origem em um ambiente de desenvolvimento usando:

SQL Server Management Studio por meio do provedor MSSCCI,
Ferramentas de dados do Visual Studio e SQL Server
Uma ferramenta de terceiros ApexSQL Source Control

Aqui na Red Gate oferecemos uma ferramenta, Controle de origem SQL, que usa a tecnologia SQL Compare para vincular seu banco de dados a um repositório TFS ou SVN.Esta ferramenta integra-se ao SSMS e permite que você trabalhe normalmente, exceto que agora permite confirmar os objetos.

Para uma abordagem baseada em migrações (mais adequada para implantações automatizadas), oferecemos Automação de alterações SQL (anteriormente chamado de ReadyRoll), que cria e gerencia um conjunto de scripts incrementais como um projeto do Visual Studio.

No SQL Source Control é possível especificar tabelas de dados estáticos.Eles são armazenados no controle de origem como instruções INSERT.

Se você estiver falando sobre dados de teste, recomendamos que você gere dados de teste com uma ferramenta ou por meio de um script pós-implantação definido por você, ou simplesmente restaure um backup de produção para o ambiente de desenvolvimento.

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

+1 para todos que recomendaram as ferramentas RedGate, com uma recomendação adicional e uma advertência.

SqlCompare também possui uma API bem documentada:para que você possa, por exemplo, escrever um aplicativo de console que sincronize sua pasta de scripts controlada por origem com um banco de dados de teste de integração de CI no check-in, para que quando alguém fizer check-in de uma alteração no esquema de sua pasta de scripts, ela seja automaticamente implantada junto com o aplicativo correspondente mudança de código.Isso ajuda a fechar a lacuna com os desenvolvedores que se esquecem de propagar alterações em seu banco de dados local para um banco de dados de desenvolvimento compartilhado (cerca de metade de nós, eu acho :)).

Uma ressalva é que, com uma solução com script ou não, as ferramentas RedGate são suficientemente suaves para que seja fácil esquecer as realidades SQL subjacentes à abstração.Se você renomear todas as colunas de uma tabela, o SqlCompare não terá como mapear as colunas antigas para as novas colunas e eliminará todos os dados da tabela.Isso irá gerar avisos, mas já vi pessoas clicarem além disso.Há um ponto geral que vale a pena ressaltar, eu acho, que você só pode automatizar o versionamento e atualização do banco de dados até agora - as abstrações são muito vazadas.

Nós usamos DBGhost para gerenciar nosso banco de dados SQL.Em seguida, você coloca seus scripts para construir um novo banco de dados em seu controle de versão, e ele construirá um novo banco de dados ou atualizará 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 ainda possa fazer isso, se, por exemplo, quiser alterar o tipo de dados de uma coluna e precisar converter os dados).

Com o VS 2010, use o projeto Database.

Script do seu banco de dados
Faça alterações nos scripts ou diretamente no seu servidor de banco de dados
Sincronize usando dados> Schema Compare

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

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

Acho 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 metadados de banco de dados, que informam quais bancos de dados estão em qual estado de desenvolvimento e quais tabelas contêm dados controláveis por versão e assim por diante.

Você também pode procurar uma solução de migração.Eles permitem que você especifique o esquema do seu banco de dados em código C# e aumente e diminua a versão do seu banco de dados usando o MSBuild.

Atualmente estou usando DbUp, e tem funcionado bem.

Você não mencionou nenhum detalhe específico sobre seu ambiente ou restrições de destino, portanto isso pode não ser totalmente aplicável...mas se você está procurando uma maneira de rastrear efetivamente um esquema de banco de dados em evolução e não é adverso à ideia de usar Ruby, as migrações do ActiveRecord são a sua escolha.

As migrações definem programaticamente as transformações do banco de dados usando uma Ruby DSL;cada transformação pode ser aplicada ou (geralmente) revertida, permitindo que você pule para uma versão diferente do seu esquema de banco de dados a qualquer momento.O arquivo que define essas transformações pode ser verificado no controle de versão como qualquer outro trecho de código-fonte.

Porque as migrações fazem parte Registro ativo, eles normalmente são usados em aplicativos Rails full-stack;entretanto, você pode usar o ActiveRecord independente do Rails com esforço mínimo.Ver aqui para um tratamento mais detalhado do uso de migrações de AR fora do Rails.

Todo banco de dados deve estar sob controle do código-fonte.O que falta é uma ferramenta para criar scripts automáticos de todos os objetos do banco de dados - e "dados de configuração" - para um arquivo, que pode então ser adicionado a qualquer sistema de controle de origem.Se você estiver usando o SQL Server, minha solução está aqui: http://dbsourcetools.codeplex.com/ .Divirta-se.- Natan.

É simples.

Quando o projeto base estiver pronto, você deverá criar um script de banco de dados completo.Este script está comprometido com o SVN.É a primeira versão.
Depois disso todos os desenvolvedores criam scripts de mudança (ALTER..., novas tabelas, sprocs, etc).
Quando precisar da versão atual, você deverá executar todos os novos scripts de alteração.
Quando o aplicativo é lançado para produção, você volta para 1 (mas será uma versão sucessiva, é claro).

Nant irá ajudá-lo a executar esses scripts de mudança.:)

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

Se você tem um banco de dados pequeno e deseja versionar tudo, este script em lote pode ajudar.Ele desanexa, compacta e verifica um arquivo MDF de banco de dados MSSQL no Subversion.

Se você deseja principalmente versionar seu esquema e ter apenas uma pequena quantidade de dados de referência, você pode usar Migrações SubSônicas para lidar com isso.A vantagem é que você pode migrar facilmente para cima ou para baixo para qualquer versão específica.

Para tornar o dump para 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 de versão em sysobjects.

Configurar: Crie uma tabela em cada banco de dados que você deseja verificar incrementalmente para conter as informações da versão da última vez que você verificou (vazia na primeira execução).Limpe esta tabela se desejar verificar novamente toda a sua 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 deste sql e gerar scripts sql apenas para aqueles de seu interesse e colocá-los em um 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

Observação: Se você usar um agrupamento não padrão em qualquer um dos seus bancos de dados, precisará substituir /* COLLATE */ com seu agrupamento de banco de dados.ou seja COLLATE Latin1_General_CI_AI

Como nosso aplicativo precisa funcionar em vários RDBMSs, armazenamos nossa definição de esquema no controle de versão usando o banco de dados neutro Torque formato (XML).Também controlamos a versão dos dados de referência do nosso banco de dados no formato XML da seguinte forma (onde "Relacionamento" é uma das tabelas de referência):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Em seguida, usamos ferramentas desenvolvidas internamente para gerar os scripts de atualização de esquema e de atualização de dados de referência necessários para passar da versão X do banco de dados para a versão X + 1.

Não armazenamos o esquema do banco de dados, armazenamos as alterações no banco de dados.O que fazemos é armazenar as alterações de esquema para construir um script de alteração 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 nosso 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.

Tivemos a necessidade de versionar nosso banco de dados SQL após migrarmos para uma plataforma x64 e nossa versão antiga quebrou com a migração.Escrevemos um aplicativo C# que usou SQLDMO para mapear todos os objetos SQL para uma pasta:

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

O aplicativo então compararia a versão recém-escrita com a versão armazenada no SVN e, se houvesse diferenças, atualizaria o SVN.Determinamos que executar o processo uma vez por noite era suficiente, pois não fazemos muitas alterações no SQL.Ele nos permite rastrear alterações em todos os objetos de nosso interesse, além de nos permitir reconstruir nosso esquema completo no caso de um problema sério.

Eu escrevi este aplicativo há um tempo, http://sqlschemasourcectrl.codeplex.com/ que irá verificar seus bancos de dados MSFT SQL com a freqüência que você desejar e despejar automaticamente seus objetos (tabelas, visualizações, procs, funções, configurações sql) no SVN.Funciona como um encanto.Eu uso com Unfuddle (que me permite receber alertas em checkins)

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.

Observação:Você pode querer fazer backup do dump do banco de dados em vez de colocá-lo no controle de versão.Os arquivos podem ficar muito rápidos no controle de versão e fazer com que todo o seu sistema de controle de origem fique lento (estou me lembrando de uma história de terror do CVS no momento).

Acabamos de começar a usar o Team Foundation Server.Se o seu banco de dados for de tamanho médio, o Visual Studio terá algumas integrações de projeto interessantes com comparação integrada, comparação de dados, ferramentas de refatoração de banco de dados, estrutura de teste de banco de dados e até mesmo ferramentas de geração de dados.

Porém, esse modelo não se ajusta muito bem a bancos de dados muito grandes ou de terceiros (que criptografam objetos).Então, o que fizemos foi armazenar apenas nossos objetos customizados.O servidor Visual Studio/Team Foundation funciona muito bem para isso.

Arco principal do banco de dados TFS.blog

Site MS TFS

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

Algumas características 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 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 (somente sql server ...ainda trabalhando no mysql)

O código está hospedado no Google Code.Por favor, verifique o código do Google para mais informações

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

Há um tempo atrás eu encontrei um módulo bas VB que usava objetos DMO e VSS para obter um script de banco de dados inteiro dentro do VSS.Eu transformei em um script VB e postei aqui.Você poderia facilmente realizar as chamadas VSS e usar o material DMO para gerar todos os scripts e, em seguida, chamar o SVN do mesmo arquivo em lote que chama o VBScript para fazer check-in?

David J.

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,passar de 1,1 para 1,2).Quando implantado, ele analisa a versão atual e executa os scripts um por um até atingir a última versão do aplicativo.Não há nenhum script que tenha a versão 'final' direta, mesmo a implantação em um banco de dados limpo faz a implantação por meio de uma série de etapas de atualização.

Agora, o que gostaria de acrescentar é que vi há dois dias 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ê definitivamente deveria dar uma olhada, os novos recursos são focados em manter a definição de esquema em scripts T-SQL (CREATEs), um mecanismo delta de tempo de execução para comparar o esquema de implantação com o esquema definido e fazer os ALTERs delta e integração com integração de código-fonte, até e incluindo integração contínua do MSBUILD para quedas automatizadas de build.O drop conterá um novo tipo de arquivo, os arquivos .dbschema, que podem ser levados para o site de implantação e uma ferramenta de linha de comando pode fazer os 'deltas' reais e executar a implantação.Eu tenho uma entrada no blog sobre este tópico com links para downloads do VSDE, você deve dar uma olhada: http://rusanu.com/2009/05/15/version-control-and-your-database/

É uma questão muito antiga, porém muitos estão tentando resolvê-la até agora.Tudo o que eles precisam fazer é pesquisar sobre projetos de banco de dados do Visual Studio.Sem isso, qualquer desenvolvimento de banco de dados parece muito fraco.Da organização do código à implantação e ao controle de versão, tudo simplifica.

Na minha experiência, a solução é dupla:

Você precisa lidar com as alterações no banco de dados de desenvolvimento feitas por vários desenvolvedores durante o desenvolvimento.
Você precisa lidar com atualizações de banco de dados nos sites dos clientes.

Para lidar com o número 1, você precisará de uma ferramenta forte de comparação/mesclagem de banco de dados.A melhor ferramenta deve ser capaz de realizar a mesclagem automática tanto quanto possível, permitindo que você resolva conflitos não tratados manualmente.

A ferramenta perfeita deve lidar com operações de mesclagem usando um algoritmo de mesclagem de 3 vias que leva em consideração as alterações feitas no banco de dados THEIRS e no banco de dados MINE, em relação ao banco de dados BASE.

Escrevi uma ferramenta comercial que fornece suporte de mesclagem manual para bancos de dados SQLite e atualmente estou adicionando suporte para algoritmo de mesclagem de 3 vias para SQLite.Confira em http://www.sqlitecompare.com

Para lidar com o número 2, você precisará de uma estrutura de atualização implementada.

A ideia básica é desenvolver uma estrutura de atualização automática que saiba como atualizar de um esquema SQL existente para o esquema SQL mais recente e possa construir um caminho de atualização para cada instalação de banco de dados existente.

Confira meu artigo sobre o assunto em http://www.codeproject.com/KB/database/sqlite_upgrade.aspx para ter uma ideia geral do que estou falando.

Boa sorte

Liron Levi

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

Eu sugeriria usar ferramentas de comparação para improvisar um sistema de controle de versão para seu banco de dados.Uma boa alternativa são Comparação de esquema xSQL e Comparação de dados xSQL.

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

Infelizmente, se você também deseja ter os dados sob controle de versão, pode usar o xSQL Data Compare para gerar scripts de alteração para seu banco de dados e adicionar os arquivos .sql em seu controle de versão.Você pode então executar esses scripts para reverter/atualizar para qualquer versão desejada.Tenha em mente que para a funcionalidade 'reverter' você precisa gerar scripts de mudança que quando executados tornarão a Versão 3 igual à Versão 2 e para a funcionalidade 'atualizar', você precisa gerar scripts de mudança que fazem o oposto.

Por último, 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.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow