it-swarm-pt.tech

Procedimentos armazenados / esquema de banco de dados no controle de origem

Vocês acompanham os procedimentos armazenados e o esquema do banco de dados em seu sistema de controle de origem de sua escolha?

Quando você faz uma alteração (adicione uma tabela, atualize um processo armazenado, como você obtém as alterações no controle de origem?

Usamos o SQL Server no trabalho e comecei a usar darcs para controle de versão, mas ficaria curioso sobre estratégias gerais e ferramentas úteis.

Edit: Uau, obrigado por todas as ótimas sugestões, pessoal! Eu gostaria de poder selecionar mais de uma "Resposta Aceita"!

68
Dana

Optamos por criar um script de tudo, e isso inclui todos os procedimentos armazenados e alterações de esquema. Nenhuma ferramenta wysiwyg e nenhum programa sofisticado de 'sincronização' são necessários.

As alterações de esquema são fáceis, tudo o que você precisa fazer é criar e manter um único arquivo para essa versão, incluindo todas as alterações de esquema e dados. Este é o seu script de conversão da versão x para x + 1. Em seguida, você pode executá-lo em um backup de produção e integrá-lo ao seu 'build diário' para verificar se ele funciona sem erros. Observe que é importante não alterar ou excluir o esquema/dados já gravados carregando o sql, pois você pode acabar quebrando qualquer sql gravado posteriormente.

-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO

-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO

Para procedimentos armazenados, elegemos um único arquivo por sproc, e ele usa o formulário soltar/criar. Todos os procedimentos armazenados são recriados na implantação. A desvantagem é que, se uma alteração foi feita fora do controle de origem, a alteração será perdida. Ao mesmo tempo, isso é verdade para qualquer código, mas o seu DBA'a precisa estar ciente disso. Isso realmente impede as pessoas de fora da equipe de mexer com seus procedimentos armazenados, pois as alterações são perdidas em uma atualização.

Usando o Sql Server, a sintaxe é assim:

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO

CREATE PROCEDURE [usp_MyProc]
(
    @UserID INT
)
AS

SET NOCOUNT ON

-- stored procedure logic.

SET NOCOUNT OFF

GO  

A única coisa a fazer é escrever um programa utilitário que agrupe todos os arquivos individuais e cria um novo arquivo com todo o conjunto de atualizações (como um único script). Faça isso adicionando primeiro as alterações do esquema e depois recorrendo novamente à estrutura de diretórios e incluindo todos os arquivos de procedimentos armazenados.

Como uma vantagem de criar scripts para tudo, você se tornará muito melhor na leitura e gravação de SQL. Você também pode tornar todo esse processo mais elaborado, mas este é o formato básico de como controlar todo o sql de origem sem nenhum software especial.

adendo: Rick está certo de que você perderá permissões nos procedimentos armazenados com DROP/CREATE; portanto, talvez seja necessário escrever outro script para reativar permissões específicas. Esse script de permissão seria o último a ser executado. Nossa experiência encontrou mais problemas com a ALTER nos versos DROP/CREATE semântica. YMMV

43
Robert Paulson

crie um "projeto de banco de dados" no Visual Studio para gravar e gerenciar seu código sQL e manter o projeto sob controle de versão junto com o restante da sua solução.

8
Manu

A solução que usamos no meu último trabalho foi numerar os scripts conforme eles foram adicionados ao controle de origem:

01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql

A idéia era que sempre soubéssemos qual ordem executar os scripts e poderíamos evitar o gerenciamento de problemas de integridade de dados que poderiam surgir se você tentasse modificar o script nº 1 (o que presumivelmente causaria a falha dos INSERTs no nº 2).

8
japollock

Eu concordo com a prática de Robert Paulson. Isso pressupõe que você esteja no controle de uma equipe de desenvolvimento com a responsabilidade e a disciplina de aderir a essa prática.

Para "forçar" isso para minhas equipes, nossas soluções mantêm pelo menos um projeto de banco de dados de Visual Studio Team Edition para profissionais de banco de dados . Como em outros projetos na solução, o projeto de banco de dados obtém controle de versão. Torna-se um processo natural de desenvolvimento dividir tudo no banco de dados em partes que podem ser mantidas, "disciplinando" minha equipe ao longo do caminho.

Obviamente, sendo um projeto do Visual Studio, não é nem perto de ser perfeito. Você encontrará muitas peculiaridades que podem frustrá-lo ou confundi-lo. É preciso um bom entendimento de como o projeto funciona antes de realizar suas tarefas. Exemplos incluem

Mas para equipes que não praticam o controle de versão de seus objetos de banco de dados, este é um bom começo. A outra alternativa famosa é, obviamente, conjunto de produtos SQL Server da Red Gate , que a maioria das pessoas que os utiliza consideram superior à oferta da Microsoft.

5
icelava

Um aspecto a ter em mente com seus scripts de eliminação/criação no SQL Server é que as permissões no nível do objeto serão perdidas. Alteramos nosso padrão para usar scripts ALTER, o que mantém essas permissões.

Existem algumas outras ressalvas, como o fato de soltar um objeto descarta os registros de dependência usados ​​por sp_depends e a criação do objeto cria apenas as dependências para esse objeto. Portanto, se você soltar/criar uma visão, os sp_depends não saberão mais de nenhum objeto que faça referência a essa visão.

Moral da história, use scripts ALTER.

5
Rick

Eu acho que você deve escrever um script que configure automaticamente seu banco de dados, incluindo quaisquer procedimentos armazenados. Esse script deve ser colocado no controle de origem.

4
Adrian Mouat

Par perspectivas diferentes da minha experiência. No mundo Oracle, tudo era gerenciado por scripts "create" DDL. Como ahockley mencionou, um script para cada objeto. Se o objeto precisar mudar, seu script DDL será modificado. Há um script de invólucro que chama todos os scripts de objeto para que você possa implantar a construção atual do banco de dados no ambiente que desejar. Isto é para o núcleo principal criar.

Obviamente, em um aplicativo ao vivo, sempre que você envia uma nova compilação que requer, por exemplo, uma nova coluna, você não descarta a tabela e a cria nova. Você fará um script ALTER e adicionará a coluna. Portanto, toda vez que esse tipo de mudança precisa ocorrer, sempre há duas coisas a serem feitas: 1) escreva o DDL do alter e 2) atualize o DDL de criação do núcleo para refletir a alteração. Ambos entram no controle de origem, mas o script de alteração única é mais uma mudança momentânea no tempo, pois será usado apenas para aplicar um delta.

Você também pode usar uma ferramenta como o ERWin para atualizar o modelo e gerar o DDL para a frente, mas a maioria dos DBAs que conheço não confia em uma ferramenta de modelagem para gerar o script exatamente da maneira que eles desejam. Você também pode usar o ERWin para fazer a engenharia reversa do script DDL principal em um modelo periodicamente, mas é muito complicado fazer com que pareça certo (toda vez que você faz isso).

No mundo da Microsoft, empregamos uma tática semelhante, mas usamos o produto Red Gate para ajudar a gerenciar os scripts e deltas. Ainda coloque os scripts no controle de origem. Ainda um script por objeto (tabela, sproc, qualquer que seja). No começo, alguns dos DBAs realmente preferiam usar a GUI do SQL Server para gerenciar os objetos, em vez de usar scripts. Mas isso dificultava o gerenciamento consistente da empresa, à medida que ela crescia.

Se o DDL estiver no controle de origem, é trivial usar qualquer ferramenta de construção (geralmente ant) ​​para escrever um script de implantação.

3
Ed Lucas

Descobri que, de longe, a maneira mais fácil, rápida e segura de fazer isso é apenas morder a bala e usar o SQL Source Control da RedGate. Com script e armazenado no repositório em questão de minutos. Eu só gostaria que a RedGate olhasse o produto como um líder de perdas, para que ele pudesse ter um uso mais amplo.

3
anopres

Em experiências anteriores, eu mantive a fonte de alterações do banco de dados controlada de tal maneira que, para cada versão do produto, todas as alterações no banco de dados eram sempre escritas e armazenadas no script em que estamos trabalhando. O processo de compilação no local traria automaticamente o banco de dados para a versão atual com base em uma tabela no banco de dados que armazenava a versão atual para cada "aplicativo". Um aplicativo utilitário .net personalizado que escrevemos executaria e determinaria a versão atual do banco de dados e executaria quaisquer novos scripts contra ele na ordem dos números de prefixo dos scripts. Em seguida, executávamos testes de unidade para garantir que tudo estivesse bem.

Armazenamos os scripts no controle de origem da seguinte forma (estrutura de pastas abaixo):

Estou um pouco enferrujado com as convenções de nomenclatura atuais em tabelas e procedimentos armazenados tão vazios com o meu exemplo ...

[raiz]
[inscrição]
[Versão]
[roteiro]

\ scripts
Minha aplicação\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql

Com o uso de uma tabela Versions que levaria em conta o Aplicativo e a Versão, o aplicativo restauraria o backup semanal da produção e executaria todos os scripts necessários no banco de dados desde a versão atual. Usando o .net, conseguimos facilmente empacotar isso em uma transação e, se alguma coisa falhasse, reverteríamos e enviaríamos e-mails, então sabíamos que o lançamento tinha scripts ruins.

Portanto, todos os desenvolvedores devem manter isso no controle de origem, para que o release coordenado garanta que todos os scripts que planejamos executar no banco de dados sejam executados com êxito.

Provavelmente, é mais informação do que você procurava, mas funcionou muito bem para nós e, dada a estrutura, foi fácil envolver todos os desenvolvedores.

Quando o dia do lançamento chegava, a equipe de operações seguia as notas de lançamento e pegava os scripts no controle de origem e executava o pacote no banco de dados com o aplicativo .net que usamos durante o processo noturno de compilação, que empacotaria automaticamente os scripts nas transações. algo falhou, ele reverteria automaticamente e nenhum impacto no banco de dados foi feito.

2
Dean Poulin

Semelhante a Robert Paulson, acima, nossa organização mantém o banco de dados sob controle de origem. No entanto, nossa diferença é que tentamos limitar o número de scripts que temos.

Para qualquer novo projeto, há um procedimento definido. Temos um script de criação de esquema na versão 1, um script de criação de proc armazenado e possivelmente um script de criação de carregamento de dados inicial. Todos os procs são mantidos em um único arquivo, reconhecidamente maciço. Se estivermos usando a Enterprise Library, incluiremos uma cópia do script de criação para o log; se for um projeto ASP.NET usando a estrutura de aplicativos ASP.NET (autenticação, personalização etc.), também incluiremos esse script. (Nós o geramos a partir das ferramentas da Microsoft e o aprimoramos até funcionar de maneira replicável em sites diferentes. Não é divertido, mas é um investimento valioso em tempo.)

Usamos a mágica CTRL + F para encontrar o processo que gostamos. :) (Adoraríamos que o SQL Management Studio tivesse navegação de código como o VS. Suspiro!)

Para versões subsequentes, geralmente temos os scripts upgradeSchema, upgradeProc e/ou updateDate. Para atualizações de esquema, ALTERAMOS as tabelas o máximo possível, criando novas conforme necessário. Para atualizações proc, DROP e CREATE.

Uma ruga aparece com essa abordagem. É fácil gerar um banco de dados e atualizar rapidamente um novo banco de dados na versão atual do banco de dados. No entanto, é necessário ter cuidado com a geração do DAL (o que atualmente - normalmente fazemos com o SubSonic), para garantir que as alterações no DB/schema/proc sejam sincronizadas de maneira limpa com o código usado para acessá-los. No entanto, em nossos caminhos de construção, há um arquivo em lotes que gera o SubSonic DAL; portanto, é nossa SOP fazer check-out do código DAL, executar novamente esse arquivo em lotes e verificar tudo novamente a qualquer momento). mudança de esquema e/ou procs. (Isso, é claro, aciona uma compilação de origem, atualizando dependências compartilhadas para as DLLs apropriadas ...)

2
John Rudy

Na minha empresa, tendemos a armazenar todos os itens do banco de dados no controle de origem como scripts individuais, assim como faria com arquivos de código individuais. Todas as atualizações são feitas primeiro no banco de dados e depois migradas para o repositório de código-fonte, para que seja mantido um histórico de alterações.
Como uma segunda etapa, todas as alterações no banco de dados são migradas para um banco de dados de integração. Esse banco de dados de integração representa exatamente a aparência do banco de dados de produção após a implantação. Também temos um banco de dados de controle de qualidade que representa o estado atual da produção (ou a última implantação). Depois que todas as alterações são feitas no banco de dados Integration, usamos uma ferramenta diff de esquema (SQL Diff do Red Gate para SQL Server) para gerar um script que migrará todas as alterações de um banco de dados para outro.
Descobrimos que isso é bastante eficaz, pois gera um único script que podemos integrar facilmente aos nossos instaladores. O maior problema que geralmente temos é que os desenvolvedores esquecem de migrar suas alterações para a integração.

1
Mitch

Os procedimentos armazenados obtêm 1 arquivo por sp com o padrão, se houver, descarte/crie instruções na parte superior. As visualizações e funções também obtêm seus próprios arquivos, facilitando a versão e a reutilização.

O esquema é todo o script 1 para começar, depois faremos alterações de versão.

Tudo isso é armazenado em um projeto de banco de dados do visual studio conectado ao TFS (@ work ou VisualSVN Server @ home para itens pessoais) com uma estrutura de pastas da seguinte maneira:
- projeto
-- funções
- esquema
-- procedimentos armazenados
-- Visualizações

1
knight0323

Temos usado uma abordagem alternativa no meu projeto atual - não temos o banco de dados sob controle de origem, mas usamos uma ferramenta de comparação de banco de dados para criar scripts das alterações quando chegamos a cada release.
Ele tem funcionado muito bem até agora.

0
Rikalous

Mantemos procedimentos armazenados no controle de origem.

0
Darren Kopp

Armazenamos tudo relacionado a um aplicativo em nosso SCM. Os scripts do banco de dados geralmente são armazenados em seu próprio projeto, mas são tratados como qualquer outro código ... projetar, implementar, testar, confirmar.

0
Chris Hall

Script tudo (criação de objeto, etc) e armazene esses scripts no controle de origem. Como as mudanças chegam lá? Faz parte da prática padrão de como as coisas são feitas. Precisa adicionar uma tabela? Escreva um script CREATE TABLE. Atualizar um sproc? Edite o script do procedimento armazenado.

Eu prefiro um script por objeto.

0
ahockley

Para procs, escreva os procs com wrappers de script em arquivos simples e aplique as alterações desses arquivos. Se aplicado corretamente, você poderá fazer o check-in desse arquivo e poderá reproduzi-lo também.

Para alterações de esquema, pode ser necessário fazer check-in de scripts para fazer as alterações feitas de maneira incremental. Escreva o script, aplique-o e faça check-in. Você pode criar um processo para aplicar automaticamente cada script de esquema em série.

0
John Flinchbaugh

Mantemos os procedimentos armazenados no controle de origem. A maneira como nós (ou pelo menos eu) o fazemos é adicionar uma pasta ao meu projeto, adicionar um arquivo para cada SP e copiar manualmente, cole o código nele. Então, quando altero o SP , Preciso alterar manualmente o arquivo que o controle de origem.

Gostaria de saber se as pessoas podem fazer isso automaticamente.

0
Rik