banco de dados de versões SQL Server

votos
288

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

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

Publicado 01/08/2008 em 19:33
fonte usuário
Em outras línguas...                            


29 respostas

votos
169

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

Para uma aplicação web, onde eu vou ter uma instância de banco de dados de produção único, eu uso duas técnicas:

Scripts de atualização de banco de dados

Uma base de dados de sequência de atualizar scripts que contêm o DDL necessário para mover o esquema de versão N para N + 1. (Estes vão em 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 cada vez que um script de atualização é executado, que corresponde à nova versão.

Isso garante que é fácil de ver qual a versão do esquema do banco de dados existe e que os scripts de atualização de banco de dados são executados apenas uma vez. Novamente, estes são não dumps de banco de dados. Em vez disso, cada script representa as mudanças necessárias para se mover de uma versão para a próxima. Eles são o script que você aplica a sua base de dados de produção para "upgrade"-lo.

Sincronização Sandbox desenvolvedor

  1. Um script para backup, higienizar, e encolher um banco de dados de produção. Executar este depois de cada atualização para a produção DB.
  2. Um script para restaurar (e ajustar, se necessário) o backup em uma estação de trabalho do desenvolvedor. Cada desenvolvedor executa este script depois de cada atualização para a produção DB.

Uma ressalva: Meus testes automatizados executar contra um banco de dados esquema correto, mas vazio, de modo que este conselho não será perfeitamente atender às suas necessidades.

Respondeu 02/08/2008 em 18:33
fonte usuário

votos
42

produto SQL Compare de Red Gate não só permite que você faça comparações no nível do objeto, e gerar scripts de alteração de que, mas também permite exportar seus objetos de banco de dados em uma hierarquia de pastas organizadas por tipo de objeto, com um [nome do objeto] .sql criação roteiro por objeto nestes diretórios. A hierarquia de tipo de objeto é assim:

\ Funções
\ Segurança
\ Segurança \ Funções
\ Security \ Schemas
\ Security \ Users
\ Stored Procedures
\ Tables

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

Respondeu 26/08/2008 em 08:23
fonte usuário

votos
38

Este é um dos "problemas difíceis" em torno do desenvolvimento. Tanto quanto eu sei que não existem soluções perfeitas.

Se você só precisa armazenar a estrutura de banco de dados e não os dados que você pode exportar o banco de dados como consultas SQL. (Em Enterprise Manager: Clique direito no banco de dados -> Gerar script SQL Eu recomendo definindo a "criar um arquivo por objeto" na guia Opções.) Você pode então cometer esses arquivos de texto para o SVN e fazer uso das funções diff e registro do SVN.

Tenho esta amarrado junto com um script em lotes que leva um parâmetro de um casal e configura o banco de dados. Eu também acrescentou algumas consultas adicionais que entram dados padrão como tipos de usuário e o usuário admin. (Se você quiser mais informações sobre este assunto, postar alguma coisa e eu posso colocar o script em algum lugar acessível)

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

Respondeu 01/08/2008 em 20:28
fonte usuário

votos
37

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

  • sistema centralizado Version Control - um sistema padrão onde os usuários verificar out / check-in antes / depois de trabalhar em arquivos, e os arquivos estão sendo mantidos em um único servidor central

  • Distribuído sistema de controle de versão - um sistema onde o repositório está sendo clonado, e cada clone é realmente o backup completo do repositório, por isso, se qualquer falha no servidor, em seguida, qualquer repositório clonado pode ser usado para restaurá-lo Depois de escolher o sistema certo para as suas necessidades , você precisa configurar o repositório que é o núcleo de qualquer sistema de controle de versão Tudo isso é explicado no seguinte artigo: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -fonte-controlo-básico /

Depois de configurar um repositório, e no caso de um sistema de controle de versão 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 via o provedor MSSCCI,

  • Visual Studio e SQL Server Data Tools

  • Uma ferramenta de 3rd party Controle ApexSQL Fonte
Respondeu 24/06/2015 em 10:36
fonte usuário

votos
22

Aqui na Red Gate oferecemos uma ferramenta, controle de origem SQL , que usa SQL Compare tecnologia para vincular o seu banco de dados com um repositório TFS ou SVN. Esta ferramenta integra em SSMS e permite que você trabalhe como faria normalmente, exceto que agora permite que você cometer os objetos.

Para uma abordagem baseada em migrações (mais adequado para implantações automatizadas), oferecemos ReadyRoll , que cria e gere um conjunto de scripts incrementais como um projeto de Visual Studio.

No controle de origem SQL é possível especificar tabelas de dados estáticos. Estes são armazenados no controle de origem como INSERIR IGNORE declarações.

Se você está falando de dados de teste, recomendamos que você quer gerar dados de teste com uma ferramenta ou através de um script pós-implantação que você definir, ou você simplesmente restaurar um backup de produção para o ambiente dev.

Respondeu 01/07/2010 em 10:10
fonte usuário

votos
20

Você pode querer olhar para Liquibase ( http://www.liquibase.org/ ). Mesmo se você não usar a ferramenta em si ele lida com os conceitos de gestão de mudança de banco de dados ou refatoração muito bem.

Respondeu 16/09/2008 em 19:16
fonte usuário

votos
17

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

SqlCompare também tem uma API decentemente documentado: para que você possa, por exemplo, escrever um aplicativo de console que sincroniza a pasta seus scripts controlado de origem com um banco de dados de teste de integração CI no check-in, para que quando alguém verifica em uma mudança no esquema de sua pasta de scripts ele é automaticamente implantado junto com a mudança de código do aplicativo correspondente. Isso ajuda a diminuir a diferença com os desenvolvedores que são esquecidos sobre propagando mudanças em seu local de db até um desenvolvimento compartilhado DB (cerca de metade de nós, eu acho :)).

A ressalva é que, com uma solução de script ou de outra forma, as ferramentas RedGate são suficientemente suave que é fácil esquecer realidades SQL subjacentes à abstração. Se você renomear todas as colunas de uma tabela, SqlCompare não tem nenhuma forma de mapear as colunas antigas para as novas colunas e vai cair todos os dados na tabela. Ele irá gerar avisos mas eu vi as pessoas clicam passado que. Há um ponto geral aqui vale a pena fazer, penso eu, que você só pode automatizar DB versões e atualizar até agora - as abstrações são muito permeável.

Respondeu 15/10/2008 em 10:44
fonte usuário

votos
14

Com o VS 2010, usar o projeto de banco de dados.

  1. Script para fora seu banco de dados
  2. Fazer alterações em scripts ou diretamente em seu servidor db
  3. Sincronizar usando Dados> esquema comparar

Faz uma solução DB versionamento perfeito, e faz a sincronização DB é uma brisa.

Respondeu 25/02/2011 em 21:18
fonte usuário

votos
14

Usamos DBGhost para gerenciar nosso banco de dados SQL. Então você colocar seus scripts para construir um novo banco de dados em seu controle de versão, e ele vai quer 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 com a criação de scripts de alteração (embora você ainda pode fazer isso, se por exemplo você quiser alterar o tipo de dados de uma coluna e precisa converter dados).

Respondeu 07/08/2008 em 22:12
fonte usuário

votos
12

É uma boa abordagem para salvar scripts de banco de dados em controle de versão com scripts de alteração para que você pode atualizar qualquer um banco de dados que você tem. Além disso, você pode querer salvar esquemas para versões diferentes de modo que você pode criar um banco de dados completo sem ter de aplicar todos os scripts de alteração. Lidar com os scripts devem ser automatizado de modo que você não tem que fazer o 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 devem dispor de meios para lidar com metadados de banco de dados, que diz o que os bancos de dados estão em que estado de desenvolvimento e as tabelas que contêm versão dados controláveis ​​e assim por diante.

Respondeu 24/09/2008 em 07:11
fonte usuário

votos
11

Você também pode olhar para uma solução migrações. Estes permitem que você especifique o esquema de banco de dados em código C #, e rolar a sua versão do banco de dados para cima e para baixo usando MSBuild.

Atualmente estou usando DbUp , e tem vindo a trabalhar bem.

Respondeu 06/08/2008 em 23:51
fonte usuário

votos
10

Você não mencionou quaisquer detalhes sobre o seu ambiente de destino ou restrições, e isso não pode ser inteiramente aplicável ... mas se você está procurando uma maneira de controlar efetivamente um esquema DB evoluindo e não são adversos para a idéia de usar ruby, migrações do Active Record é o seu direito beco.

Migrações definir programaticamente transformações banco de dados usando uma conexão DSL de Ruby; cada transformação pode ser aplicada ou (geralmente) rolada para trás, permitindo-lhe saltar para uma versão diferente do seu esquema DB em qualquer ponto no tempo. O arquivo de definição dessas transformações podem ser verificados no controle de versão como qualquer outro pedaço de código-fonte.

Porque migrações são uma parte do ActiveRecord , que normalmente encontrar uso em full-stack Rails aplicativos; no entanto, você pode usar ActiveRecord independente do Rails com o mínimo esforço. Veja aqui para um tratamento mais detalhado do uso de migrações da AR fora do Rails.

Respondeu 02/08/2008 em 18:54
fonte usuário

votos
9

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

Respondeu 07/07/2009 em 13:58
fonte usuário

votos
8

É simples.

  1. Quando o projeto base está pronta, então você deve criar script de banco de dados completo. Este script está empenhada em SVN. É primeira versão.

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

  3. Quando você precisa versão atual, então você deve executar todos os novos scripts de alteração.

  4. Quando o aplicativo é liberado para produção, então você voltar para 1 (mas então será versão sucessiva é claro).

Nant irá ajudá-lo a executar esses scripts de alteração. :)

E lembre-se. Tudo funciona bem quando há disciplina. Toda vez que quando a mudança de banco de dados está comprometida funções seguida correspondentes no código estão comprometidos também.

Respondeu 16/05/2009 em 12:31
fonte usuário

votos
7

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

Configuração: Criar uma tabela em cada banco de dados que pretende verificar de forma incremental para manter as informações de versão a partir da última vez que verifiquei (vazia na primeira execução). Limpar esta tabela se você quiser re-examinar sua estrutura de dados inteiro.

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 funcionamento normal: Você pode levar os resultados a partir deste sql, e gerar scripts SQL para apenas os que você está interessado, e colocá-los em um controle de fonte 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 IGNORE  #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 IGNORE  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, você precisará substituir /* COLLATE */com o seu agrupamento de banco. ou sejaCOLLATE Latin1_General_CI_AI

Respondeu 24/09/2008 em 13:53
fonte usuário

votos
7

Porque o nosso aplicativo tem de trabalhar através de vários RDBMSs, armazenamos a nossa definição de esquema no controle de versão usando o banco de dados neutro Torque formato (XML). Também versão de controlar os dados de referência para nosso banco de dados em 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 home-grown para gerar a atualização de esquema e dados de referência atualizar scripts que são necessários para ir de X versão do banco de dados para a versão X + 1.

Respondeu 24/09/2008 em 06:49
fonte usuário

votos
7

Se você tem um pequeno banco de dados e quiser versão a coisa toda, esse script em lotes pode ajudar. Destaca, comprime, e verifica um arquivo MDF de banco de dados MSSQL no Subversion.

Se você quer principalmente para a versão do seu esquema e só tem uma pequena quantidade de dados de referência, você pode, possivelmente, usar SubSonic Migrações para lidar com isso. O benefício não é que você pode facilmente migrar para cima ou para baixo para qualquer versão específica.

Respondeu 07/08/2008 em 22:21
fonte usuário

votos
6

Eu escrevi este aplicativo há um tempo atrás, http://sqlschemasourcectrl.codeplex.com/ que irá analisar o seu SQL do db MSFT tão frequentemente como você deseja e automaticamente despejar seus objetos (tabelas, vistas, procs, funções, configurações do SQL) em SVN. Funciona como um encanto. Eu usá-lo com Unfuddle (o que me permite receber alertas sobre checkins)

Respondeu 23/09/2010 em 03:35
fonte usuário

votos
6

Tivemos a necessidade de versão nosso banco de dados SQL depois que migraram para uma plataforma x64 e nossa versão antiga rompeu com a migração. Nós escrevemos uma aplicação C # que usou SQLDMO para mapear todos os objetos SQL para uma pasta:

                Raiz
                    Nome do servidor
                       Nome do banco de dados
                          objetos de esquema
                             Gatilhos de banco de dados *
                                .ddltrigger.sql
                             Funções
                                ..function.sql
                             Segurança
                                Roles
                                   Funções de aplicação
                                      .approle.sql
                                   Funções de banco de dados
                                      .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
                             Visualizações
                                ..view.sql
                                índices
                                   ... index.sql
                                Gatilhos
                                   ... trigger.sql

O aplicativo, então, comparar a versão recém-escritos para a versão armazenada no SVN e se havia diferenças seria atualizar SVN. Nós determinamos que a execução do processo uma vez por noite foi suficiente, uma vez que não fazem que muitas mudanças para SQL. Ela nos permite rastrear alterações em todos os objetos que se preocupam mais ele nos permite reconstruir o nosso esquema completo em caso de um problema sério.

Respondeu 09/10/2008 em 15:54
fonte usuário

votos
6

Não armazenar o esquema de banco de dados, nós armazenamos as alterações para o banco de dados. O que fazemos é armazenar as alterações de esquema para que construir um script de alteração para qualquer versão do banco de dados e aplicá-lo às bases de dados dos nossos clientes. Eu escrevi um aplicativo utilitário de banco de dados que é distribuído com o nosso principal aplicativo que possa ler esse roteiro e saber quais atualizações precisam ser aplicadas. Ele também tem smarts suficientes para refrescar vistas e procedimentos armazenados conforme necessário.

Respondeu 07/08/2008 em 00:00
fonte usuário

votos
5

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

Algumas características do projeto:

  • Permite que as mudanças de esquema
  • Permite população de árvores valor
  • Permite que as inserções de dados de teste separados para, por exemplo. UAT
  • Permite opção para reversão (não automatizado)
  • Mantém suporte para o servidor SQL e Mysql
  • Tem a capacidade de importar seu banco de dados existente no controle de versão com um simples comando (servidor SQL única ... ainda está trabalhando no mysql)

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

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

Respondeu 24/02/2011 em 19:28
fonte usuário

votos
5

Nós só comecei a usar Team Foundation Server. Se seu banco de dados é de tamanho médio, em seguida, visual studio tem algumas integrações bom projeto com construído em comparar, dados comparar, ferramentas de refatoração de banco de dados, estrutura de testes de banco de dados, e até mesmo ferramentas de geração de dados.

Mas, esse modelo não se encaixa bases do partido muito grandes ou terceiros (que os objetos cifra) muito bem. Então, o que temos feito é para armazenar apenas os nossos objetos personalizados. Visual servidor fundação Estúdio / Team funciona muito bem para isso.

TFS arco-chefe de banco de dados. blogue

MS local TFS

Respondeu 22/08/2008 em 18:13
fonte usuário

votos
5

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

Dependendo da sua plataforma de desenvolvimento, pode haver plugins de código aberto disponível. Rolling seu próprio código para fazê-lo é geralmente bastante trivial.

Nota: Você pode querer fazer backup do despejo de banco de dados em vez de colocá-lo no controle de versão. Os arquivos podem obter enormes rápido no controle de versão, e fazer com que seu sistema de controle de origem inteira para se tornar lento (eu estou recordando uma história de horror CVS no momento).

Respondeu 03/08/2008 em 02:49
fonte usuário

votos
4

Eu também estou usando uma versão do banco de dados armazenados por meio do banco de dados estendido propriedades família de procedimentos. O meu pedido tem scripts para cada passo versão (isto é. Movem de 1,1 a 1,2). Quando implantado, ele olha para a versão atual e, em seguida, executa os scripts de um por um até chegar a última versão do aplicativo. Não existe um script que tem a versão em linha reta 'final', mesmo implantar em um DB limpo faz o deploy via uma série de etapas de atualização.

Agora o que eu gostaria de acrescentar é que eu vi há dois dias uma apresentação sobre o campus MS sobre o novo e próxima edição VS DB. A apresentação foi focada especificamente sobre este tema e eu fiquei fora da água. Você deve definitivamente check-out, as novas instalações estão focados na definição do esquema mantendo em scripts T-SQL (cria), um motor de tempo de execução delta para comparar esquema implantação com esquema definido e fazendo as altera delta e integração com a integração de código fonte, até e incluindo MSBUILD integração contínua para gotas de compilação automatizados. A queda irá conter um novo tipo de arquivo, os arquivos .dbschema, que podem ser tomadas para o local de implantação e uma ferramenta de linha de comando pode fazer o 'deltas' real e executar a implantação. Eu tenho uma entrada de blog sobre este tema com links para os downloads VSDE, você deve vê-los:http://rusanu.com/2009/05/15/version-control-and-your-database/

Respondeu 15/05/2009 em 20:26
fonte usuário

votos
4

Um tempo atrás eu encontrei um módulo de bas VB que é utilizado DMO e VSS objetos para obter uma db toda roteiro fora e em VSS. Eu transformou-o em um script VB e postou 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 vê-los em?

Dave J

Respondeu 16/09/2008 em 18:55
fonte usuário

votos
3

É uma questão muito antiga, porém muitos estão tentando resolver este mesmo agora. Todos eles têm de fazer é pesquisar sobre o Visual Studio Projetos de banco de dados. Sem isso, qualquer desenvolvimento de banco de dados parece muito débil. Desde a organização de código para implantação de versões, que simplifica tudo.

Respondeu 23/06/2015 em 11:26
fonte usuário

votos
2

Confira DBGhost http://www.innovartis.co.uk/ . Eu tenho usado de forma automatizada para 2 anos e agora ele funciona muito bem. Ele permite que o nosso DB constrói a acontecer muito parecido com um Java ou C construção acontece, exceto para o banco de dados. Você sabe o que eu quero dizer.

Respondeu 02/11/2009 em 23:17
fonte usuário

votos
2

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

  1. Você precisa lidar com as mudanças no banco de dados de desenvolvimento que são feitas por vários desenvolvedores durante o desenvolvimento.

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

A fim de lidar com # 1 você vai precisar de uma ferramenta de banco de dados diff / merge forte. A melhor ferramenta deve ser capaz de realizar fusão automática, tanto quanto possível, permitindo-lhe resolver sem tratamento conflitos manualmente.

A ferramenta perfeita devem manusear mesclar operações usando um algoritmo de integração de 3 modos que traz em conta as alterações que foram feitas no banco de dados deles e o banco de dados MINE, em relação ao banco de dados BASE.

Eu escrevi uma ferramenta comercial que fornece suporte merge manual para bancos de dados SQLite e atualmente estou adicionando suporte para algoritmo de integração de 3 modos para SQLite. Confira em http://www.sqlitecompare.com

A fim de lidar com # 2, você precisará de um quadro de atualização no lugar.

A idéia básica é desenvolver um quadro de atualização automática que sabe como fazer o upgrade a partir de um esquema SQL existente para o esquema SQL mais recente e pode construir um caminho de atualização para cada instalação DB existente.

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

Boa sorte

Liron Levi

Respondeu 06/08/2009 em 11:28
fonte usuário

votos
1

Gostaria de sugerir o uso de ferramentas de comparação de improvisar um sistema de controle de versão para seu banco de dados. Uma boa alternativa são xSQL esquema comparar e xSQL Data Compare .

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

Infelizmente, se você quiser ter os dados sob controle de versão, bem, você pode usar xSQL Data Compare para gerar scripts de alteração para você banco de dados e adicionar os arquivos .sql em seu controle de versão. Você poderia, então, executar esses scripts para reverter / atualização para qualquer versão que você deseja. Tenha em mente que para a funcionalidade 'revert' você precisa para gerar scripts de alteração que, quando executado fará Versão 3 o mesmo que a versão 2 e para a funcionalidade 'update', você precisa gerar scripts de alteração que fazem o oposto.

Por último, com algumas habilidades básicas de programação batch você pode automatizar todo o processo usando as versões de linha de comando de xSQL esquema comparar e xSQL Data Compare

Disclaimer: Eu estou filiado a xSQL.

Respondeu 10/01/2017 em 16:16
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more