Banco de dados de versão do SQL Server

Eu quero obter meus bancos de dados sob version control. Alguém tem algum conselho ou artigos recomendados para começar?

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

Martin Fowler escreveu meu artigo favorito sobre o assunto, http://martinfowler.com/articles/evodb.html . Eu escolho não colocar dumps de esquema no version control como alumb e outros sugerem porque eu quero uma maneira fácil de atualizar meu database de produção.

Para um aplicativo da web em que terei uma única instância do database de produção, utilizarei duas técnicas:

Scripts de atualização do database

Um script de atualização de database de seqüência que contém o DDL necessário para mover o esquema da versão N para N + 1. (Estes vão no seu sistema de version control.) Uma tabela _version_history_, algo como

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

obtém uma nova input toda vez 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 database existe e que os scripts de upgrade do database são executados apenas uma vez. Novamente, esses não são dumps de database. Em vez disso, cada script representa as alterações necessárias para passar de uma versão para outra. Eles são o script que você aplica ao seu database de produção para “atualizá-lo”.

Sincronização Sandbox do desenvolvedor

  1. Um script para fazer backup, higienizar e reduzir um database de produção. Execute isto após cada atualização para o database 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 database de produção.

Uma ressalva: meus testes automatizados são executados em um database correto, mas vazio, de modo que esse conselho não atenda perfeitamente às suas necessidades.

O produto SQL Compare do Red Gate permite fazer comparações em nível de object e gerar scripts de mudanças a partir dele, mas também permite exportar seus objects de database para uma hierarquia de pastas organizada por tipo de object, com uma criação de [objectname] .sql script por object nesses diretórios. A hierarquia de tipo de object é assim:

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

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

Este é um dos “problemas difíceis” que envolvem o desenvolvimento. Tanto quanto sei, não há soluções perfeitas.

Se você precisar apenas armazenar a estrutura do database e não os dados, poderá exportar o database como consultas SQL. (no Enterprise Manager: Clique com o botão direito no database -> Gerar script SQL. Eu recomendo configurar o “criar um arquivo por object” na aba de opções) Você pode submeter esses arquivos de texto ao svn e usar as funções diff e log do svn.

Eu tenho isso amarrado com um script em lote que leva alguns parâmetros e configura o database. 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 eu posso colocar o script em algum lugar acessível)

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

Primeiro, você deve escolher o sistema de version control certo para você:

  • Sistema de Controle de Versão Centralizado – um sistema padrão no qual os usuários fazem check-in / check-in antes / depois de trabalharem em arquivos, e os arquivos são mantidos em um único servidor central

  • Sistema Distributed Version Control – um sistema no qual o repository está sendo clonado e cada clone é o backup completo do repository, portanto, se algum servidor falhar, qualquer repository clonado poderá ser usado para restaurá-lo. Depois de escolher o sistema correto para suas necessidades , você precisará configurar o repository que é o núcleo de cada sistema de version control Tudo isso é explicado no seguinte artigo: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-basics /

Depois de configurar um repository, e no caso de um sistema de version control central de 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 através do provedor MSSCCI,

  • Ferramentas de dados do Visual Studio e do SQL Server

  • Uma ferramenta de terceiros ApexSQL Source Control

Aqui no Red Gate, oferecemos uma ferramenta, SQL Source Control , que usa a tecnologia SQL Compare para vincular seu database a um repository TFS ou SVN. Essa ferramenta integra-se ao SSMS e permite que você trabalhe como faria normalmente, exceto que agora permite comprometer os objects.

Para uma abordagem baseada em migrações (mais adequada para implantações automatizadas), oferecemos o 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. Estes 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 de pós-implantação definido, ou simplesmente restaure um backup de produção para o ambiente de desenvolvimento.

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

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

O SqlCompare também tem uma API documentada: você pode, por exemplo, criar um aplicativo de console que sincronize sua pasta de scripts controlados por fonte com um database de testes de integração de CI no checkin, para que alguém verifique uma alteração no esquema da pasta de scripts. Ele é implantado automaticamente junto com a alteração do código do aplicativo correspondente. Isso ajuda a fechar a lacuna com os desenvolvedores que estão esquecidos sobre a propagação de alterações em seu database local para um database 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 do RedGate são suaves o suficiente para que seja fácil esquecer as realidades SQL subjacentes à abstração. Se você renomear todas as colunas em uma tabela, o SqlCompare não tem como mapear as colunas antigas para as novas colunas e soltará todos os dados na tabela. Ele irá gerar avisos, mas eu vi pessoas clicarem depois disso. Há um ponto geral que vale a pena fazer, penso eu, que você só pode automatizar a versão do database e atualizar até agora – as abstrações são muito permeáveis.

Nós usamos o DBGhost para gerenciar nosso database SQL. Em seguida, você coloca seus scripts para criar um novo database em seu version control e ele pode criar um novo database ou atualizar qualquer database existente para o esquema no version control. Dessa forma, você não precisa se preocupar em criar scripts de alteração (embora ainda seja possível fazer isso, por exemplo, se desejar alterar o tipo de dados de uma coluna e precisar converter dados).

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

  1. Script seu database
  2. Faça alterações nos scripts ou diretamente no seu servidor db
  3. Sincronize usando Data> Schema Compare

Torna uma solução de versão de database perfeita e facilita muito a synchronization de DBs.

É uma boa abordagem para salvar scripts de database em version control com scripts de mudança para que você possa atualizar qualquer database que tenha. Além disso, você pode querer salvar esquemas para versões diferentes para que você possa criar um database completo sem ter que aplicar todos os scripts de mudança. O manuseio dos scripts deve ser automatizado para que você não tenha que fazer o trabalho manual.

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

A ferramenta de automatização deve ter meios para manipular os metadados do database, que informam 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.

Você não mencionou nenhum detalhe específico sobre o seu ambiente de destino ou restrições, então isso pode não ser totalmente aplicável … mas se você estiver procurando por uma maneira de rastrear efetivamente um esquema de database em evolução e não for adverso à idéia de usar Ruby, as migrações do ActiveRecord estão no seu beco.

Migrações programaticamente definem transformações de database usando uma DSL Ruby; Cada transformação pode ser aplicada ou (geralmente) revertida, permitindo que você salte para uma versão diferente do seu esquema de database em qualquer momento específico. O arquivo que define essas transformações pode ser verificado no version control como qualquer outra parte do código-fonte.

Como as migrações fazem parte do ActiveRecord , elas geralmente são usadas em aplicativos Rails com pilha completa; no entanto, você pode usar o ActiveRecord independente do Rails com o mínimo de esforço. Veja aqui um tratamento mais detalhado do uso de migrações do AR fora do Rails.

Você também pode olhar para uma solução de migrações. Eles permitem que você especifique seu esquema de database no código C # e role a versão do database para cima e para baixo usando o MSBuild.

Atualmente estou usando o DbUp e está funcionando bem.

Cada database deve estar sob controle de código-fonte. O que falta é uma ferramenta para rotear automaticamente todos os objects de database – e “dados de configuração” – para o arquivo, que pode então ser adicionado a qualquer sistema de controle de origem. Se você está usando o SQL Server, então a minha solução está aqui: http://dbsourcetools.codeplex.com/ . Diverta-se. Nathan.

É simples.

  1. Quando o projeto base estiver pronto, você deverá criar um script de database completo. Este script está comprometido com o SVN. É a primeira versão.

  2. Depois disso, todos os desenvolvedores criam scripts de mudança (ALTER …, novas tabelas, sprocs, etc).

  3. Quando você precisa da versão atual, você deve executar todos os novos scripts de mudança.

  4. Quando o aplicativo é liberado para produção, você volta para 1 (mas depois será uma versão sucessiva).

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

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

Se você tiver um database pequeno e quiser fazer a versão inteira, esse script em lote pode ajudar. Ele desanexa, compacta e verifica um arquivo MDF do database MSSQL no Subversion.

Se você deseja principalmente a versão do seu esquema e apenas uma pequena quantidade de dados de referência, é possível usar as Migrações SubSônicas para lidar com isso. O benefício é que você pode facilmente migrar 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 objects foram alterados desde a última vez usando as informações de versão em sysobjects.

Configuração: Crie uma tabela em cada database que você deseja verificar incrementalmente para manter as informações da versão da última vez que você a verificou (vazia na primeira execução). Limpe esta tabela se você quiser 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 obter os resultados deste sql e gerar scripts em sql apenas para aqueles em que está interessado 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 

Nota: Se você usar um agrupamento não padrão em qualquer um dos seus bancos de dados, será necessário replace /* COLLATE */ pelo agrupamento de database. ou seja, COLLATE Latin1_General_CI_AI

Como nosso aplicativo precisa funcionar em vários RDBMSs, armazenamos nossa definição de esquema no version control usando o formato Torque (XML) com base no database. Também controlamos a versão dos dados de referência para nosso database no formato XML da seguinte maneira (onde “Relacionamento” é uma das tabelas de referência):

    etc. 

Em seguida, usamos ferramentas internas para gerar a atualização de esquema e os scripts de atualização de dados de referência que são necessários para ir da versão X do database para a versão X + 1.

Nós não armazenamos o esquema do database, armazenamos as mudanças no database. O que fazemos é armazenar as alterações do esquema para que possamos criar um script de alteração para qualquer versão do database e aplicá-lo aos bancos de dados de nossos clientes. Eu escrevi um aplicativo de utilitário de database que é distribuído com o 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 modos de exibição e stored procedures conforme necessário.

Tivemos a necessidade de atualizar nosso database SQL depois que migramos para uma plataforma x64 e nossa versão antiga rompeu com a migration. Nós escrevemos um aplicativo C # que usava SQLDMO para mapear todos os objects SQL para uma pasta:

                 Raiz
                     Nome do servidor
                        Nome do database
                           Objetos de Esquema
                              Triggers de database *
                                 .ddltrigger.sql
                              Funções
                                 ..function.sql
                              Segurança
                                 Papéis
                                    Papéis de Aplicação
                                       .approle.sql
                                    Papéis do database
                                       .role.sql
                                 Esquemas *
                                    .schema.sql
                                 Comercial
                                    .user.sql
                              Armazenamento
                                 Catálogos de texto completo *
                                    .fulltext.sql
                              Procedimentos armazenados
                                 ..proc.sql
                              Sinônimos *
                                 .synonym.sql
                              Tabelas
                                 ..table.sql
                                 Restrições
                                    ... chkconst.sql
                                    ... defconst.sql
                                 Índices
                                    ... index.sql
                                 Chaves
                                    ... fkey.sql
                                    ... pkey.sql
                                    ... ukey.sql
                                 Gatilhos
                                    ... trigger.sql
                              Tipos
                                 Tipos de dados definidos pelo usuário
                                    ..uddt.sql
                                 Coleções de esquema XML *
                                    ..xmlschema.sql
                              Views
                                 ..view.sql
                                 Índices
                                    ... index.sql
                                 Gatilhos
                                    ... trigger.sql

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

Eu escrevi este aplicativo há um tempo atrás, http://sqlschemasourcectrl.codeplex.com/ que irá varrer seus bancos de dados MSFT SQL quantas vezes quiser e automaticamente despejar seus objects (tabelas, exibições, procs, funções, configurações de sql) em SVN. Funciona como um encanto. Eu uso com Unfuddle (o que me permite receber alertas sobre checkins)

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

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

Nota: Você pode querer fazer backup do dump do database em vez de colocá-lo no version control. Os arquivos podem ficar grandes rapidamente no version control e fazer com que todo o seu sistema de controle de origem fique lento (estou lembrando uma história de terror do CVS no momento).

Acabamos de começar a usar o Team Foundation Server. Se o seu database é de tamanho médio, o visual studio tem algumas integrações de projeto com comparação, comparação de dados, ferramentas de refatoração de database, estrutura de teste de database e até mesmo ferramentas de geração de dados.

Mas, esse modelo não se encheckbox muito bem em bancos de dados muito grandes ou de terceiros (que criptografam objects). Então, o que fizemos foi armazenar apenas nossos objects personalizados. O servidor da Visual Studio / Team Foundation funciona muito bem para isso.

Arco principal do Banco de Dados do TFS. blog

Site do MS TFS

Concordo com a resposta da ESV e, por essa razão exata, iniciei um pequeno projeto há algum tempo para ajudar a manter as atualizações do database em um arquivo muito simples, que poderia então ser mantido com um código fonte longo. Ele permite atualizações fáceis para desenvolvedores, bem como para UAT e Produção. A ferramenta funciona no Sql Server e no MySql.

Alguns resources do projeto:

  • Permite alterações de esquema
  • Permite a população da tree 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 database existente para o version control com um simples comando (somente o sql server … ainda está trabalhando no mysql)

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

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

Um tempo atrás eu encontrei um módulo bas VB que usava objects DMO e VSS para obter um script inteiro em db e em VSS. Eu o transformei em um VB Script e postei aqui . Você poderia facilmente tirar as chamadas VSS e usar o material DMO para gerar todos os scripts e, em seguida, chamar SVN do mesmo arquivo em lotes que chama o VBScript para verificá-los?

Dave J

Eu também estou usando uma versão no database armazenado através da família de propriedades de propriedades estendidas do database. Meu aplicativo tem 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, em seguida, executa os scripts, um por um, até atingir a última versão do aplicativo. Não há script que tenha a versão ‘final’ direta, até mesmo implantar em um database limpo a implantação por meio de uma série de etapas de atualização.

Agora, o que eu gostaria de acrescentar é que eu 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 eu fui expulso da água. Você deve definitivamente dar uma olhada, as novas instalações estão focadas em manter a definição do esquema em scripts T-SQL (CREATEs), um mecanismo delta de runtime para comparar o esquema de implementação com o esquema definido e fazer o delta ALTERs e integração com código fonte e incluindo a continuous integration do MSBUILD para quedas de compilation automatizadas. A gota 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 input de blog sobre este tópico com links para os downloads do VSDE, você deve vê-los: http://rusanu.com/2009/05/15/version-control-and-your-database/

É uma questão muito antiga, no entanto muitos estão tentando resolver isso mesmo agora. Tudo o que eles precisam fazer é pesquisar sobre os Projetos de Banco de Dados do Visual Studio. Sem isso, qualquer desenvolvimento de database parece muito fraco. Da organização de código à implantação para version control, simplifica tudo.

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

  1. Você precisa manipular alterações no database de desenvolvimento que são feitas por vários desenvolvedores durante o desenvolvimento.

  2. Você precisa lidar com atualizações de database em sites de clientes.

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

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

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

Para lidar com o nº 2, você precisará de uma estrutura de atualização em vigor.

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 database 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 DBGhost http://www.innovartis.co.uk/ . Eu usei de forma automatizada por 2 anos e funciona muito bem. Ele permite que nossas construções de database ocorram de maneira semelhante a uma compilation Java ou C, exceto pelo database. Você sabe o que eu quero dizer.

Eu sugeriria usar ferramentas de comparação para improvisar um sistema de version control para o seu database. Uma boa alternativa é o xSQL Schema Compare e o xSQL Data Compare .

Agora, se o seu objective é ter apenas o esquema do database sob version control, você pode simplesmente usar o xSQL Schema Compare para gerar snapshots xSQL do esquema e adicionar esses arquivos ao seu version control. Do que, para reverter ou atualizar para uma versão específica, basta comparar a versão atual do database com a captura instantânea da versão de destino.

Infelizmente, se você quiser ter os dados sob version control também, você pode usar o xSQL Data Compare para gerar scripts de mudança para o seu database e adicionar os arquivos .sql no seu version control. Você pode então executar esses scripts para reverter / atualizar para qualquer versão que você quiser. 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 ‘atualização’, você precisará gerar scripts de mudança que façam o oposto.

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 do xSQL Data Compare.

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