Gerenciamento de alterações de banco de dados - configuração para scripts de criação inicial e scripts de migração subsequentes

Question

Eu tenho um fluxo de trabalho de gerenciamento de alterações de banco de dados em vigor.É baseado em scripts SQL (portanto, não é uma solução gerenciada baseada em código).

A configuração básica é assim:

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

O processo para ativar um banco de dados é executar todos os scripts iniciais e, em seguida, executar os scripts de migração sequenciais.Uma ferramenta atende aos requisitos de versão, etc.

Minha pergunta é, nesse tipo de configuração, é útil também manter isso:

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

Por "isto" quero dizer um diretório de scripts (separados por tipo de objeto) que representa a criação de scripts para ativar o atual/mais recente versão do banco de dados.

Por alguma razão, gosto muito da ideia, mas não consigo justificar concretamente a sua necessidade.Estou esquecendo de algo?

As vantagens seriam:

• Para controle de desenvolvimento e fonte, teríamos a mesma configuração de objeto por arquivo que estamos acostumados
• Para implantação, podemos ativar uma nova instância de banco de dados para a versão mais recente executando Initial+Migrate ou executando os scripts de Current/
• Para dev, não precisamos de uma instância de banco de dados em execução para fazer o desenvolvimento.Podemos fazer desenvolvimento "offline" na pasta Current/.

As desvantagens seriam:

• Para cada alteração, precisamos atualizar os scripts na pasta Current/, bem como criar um script de Migração (na pasta Migration/)

Agradecemos antecipadamente por qualquer contribuição!

Answer 1

Na verdade, esta é a melhor maneira.Por mais complicado que possa parecer, é melhor do que as alternativas de usar ferramentas semelhantes ao SQL Compare ou implantação de arquivo .schema VSDB.Eu defendi exatamente a abordagem smae já há algum tempo: Controle de versão e seu banco de dados.Meus aplicativos implantam o esquema v1 do script inicial e executam o script de atualização para cada versão.Cada script sabe como atualizar da versão N-1 para N, e somente isso.O resultado final é a versão atual.

A maior desvantagem é a falta de um arquivo .sql oficial e procure encontrar o atual versão de qualquer objeto (procedimento, tabela, visualização etc.).Mas as vantagens de poder implantar seu aplicativo qualquer versão anterior e a vantagem de implantar por meio de sistemas bem controlados e testados roteiros superam em muito a desvantagem.

Se você se sentir mal por usar este processo de implantação (script para implantar v1.em seguida, aplique v1.1, depois v1.2 ...até que finalmente você aplique a v4.5, atual), tenha isso em mente:exatamente o mesmo processo é usado internamente pelo SQL Server para atualizar o banco de dados entre versões.Ao anexar um banco de dados mais antigo, você vê o famoso 'banco de dados está executando a atualização da versão 611 para 612' e vê que a atualização vai passo a passo, não atualiza diretamente para a versão atual 651 (ou o que for atual no seu caso).A atualização também não executa uma ferramenta diff para implantar v 651 sobre v.611.Isso porque o melhor abordagem é aquela que você acabou de usar, atualize uma etapa de cada vez.

E para adicionar uma resposta real à sua pergunta, depois de postar um discurso bastante oblíquo (é um tópico sobre o qual tenho opiniões fortes, você pode dizer?):Acho que é valioso ter uma versão com script da versão atual, mas acho que deveria ser um processo de construção de integração contíguo entregável.Em outras palavras, seu servidor de construção deve construir o banco de dados atual (usando os scripts de atualização) e então, como uma etapa de construção, criar o script do banco de dados e produzir uma eliminação de construção com o script de esquema da versão atual.Mas eles devem ser usados ​​apenas como referência para pesquisa e inspeção de código, não como entrega de implantação, meu 2C.

Answer 2

Eu acho que isso apenas tornará as coisas mais complexas a longo prazo. Versões inteiras precisam viver em um único script para que você possa testar esse script em um contexto e saber que ele funcionará corretamente em outro contexto como a produção.

Answer 3

Martin,

Se você está no mundo real, seu banco de dados de produção aceita apenas atualizações - você nunca o "cria" do zero. Portanto, a coisa mais importante para você armazenar, assistir, revisar etc. é o conjunto de scripts de atualização. Esses são os scripts que chegarão à produção; portanto, esses são os únicos de importância real.

Você está fazendo a coisa certa, tornando -os primários. Mas os desenvolvedores precisam ser capazes de obter uma "imagem atual" da aparência do esquema. Os DBAs também gostam de fazer isso, embora (também) frequentemente o façam, fazendo login nos servidores de produção e disparando algum tipo de ferramenta de GUI. (caramba!)

A única reserva que tenho sobre sua abordagem é o esquema atual/anterior pelo tipo de objeto. Esses scripts devem ser gerados automaticamente, despejando o próprio banco de dados. Se você pode categorizá -los automaticamente por tipo, então ótimo! Caso contrário, faça o que puder para facilitar a navegação, mas a regra orientadora deve sempre ser "gerada automaticamente a partir de um banco de dados ao vivo".