Você usa o controle de código para os itens da sua base de dados? [fechado]

Os scripts que os criam, incluindo inserções de dados estáticos, procedimentos armazenados e afins; claro. Eles são Arquivos de texto, eles estão incluídos no projeto e são verificados dentro e fora como tudo o resto.

Os carris também têm uma tabela de 'versão' no DB que acompanha a última migração aplicada. Você pode fazer o mesmo facilmente.

Verifique O LiquiBase para gerir as alterações da base de dados usando o controlo de origem.

Você nunca deve simplesmente entrar e começar a introduzir comandos "alterar tabela" para mudar uma base de dados de produção. O projeto que eu estou no banco de dados em cada local do cliente, e assim, todas as alterações para o banco de dados é feita em dois lugares, um arquivo de despejo que é usado para criar um novo banco de dados em um novo site do cliente, e um arquivo de atualização que é executado em cada atualização que verifica o banco de dados atual número de versão contra o maior número no arquivo, e atualiza seu banco de dados no local. Assim, por exemplo, as últimas actualizações:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

A minha loja gostou tanto dessa ideia que adicionámos a funcionalidade à nossa compilação baseada em Java usando scripts shell e Ant. Integrámos o processo na nossa rotina de implantação. Seria ser bastante fácil de escrever scripts para fazer a mesma coisa em outros frameworks que não suportam DB versioning fora-da-caixa.

Os novos projectos de bases de dados no Visual Studio fornecem o controlo de origem e mudam de scripts.

Eles têm uma ferramenta legal que compara bases de dados e pode gerar um script que converte o esquema de um para o outro, ou atualiza os dados em um para combinar com o outro.

+tom

Informação adicional 2008-11-30

Tenho-o usado como um desenvolvedor do ano passado e realmente gosto. Torna fácil comparar o meu trabalho dev com a produção e gerar um script para usar para o lançamento. Não sei se faltam características que o DBAs precisa para projetos de "tipo de empresa".

Um deles é que precisas de ter uma mentalidade diferente quando usas um projecto db. A ferramenta tem um "projeto db" EM VS, que é apenas o sql, mais um gerado automaticamente a base de dados local que tem o esquema e alguns outros dados de administração -- mas nenhum dos dados da sua aplicação, mais o seu db local que você usa para o trabalho de dev de dados de app. Você raramente está ciente do db gerado automaticamente, mas você tem que saber dele lá para que você possa deixá-lo em paz :). Este db especial é claramente reconhecível porque tem um Guid em seu nome,

O projecto VS DB faz um bom trabalho ao integrar as alterações db que outros membros da equipa fizeram no seu local de trabalho. Project / associated db. mas você precisa dar o passo extra para comparar o esquema do projeto com o seu esquema dev db local e aplicar o mods. Faz sentido, mas parece estranho no início.

Os projectos DB são uma ferramenta muito poderosa. Eles não só geram scripts, mas podem aplicá-los imediatamente. Certifique-se de não destruir o seu db de produção com ele. ;)

Gosto muito dos projectos VS DB e espero usar esta ferramenta para todos os meus projectos db a avançar.

+tom

Depois de obter e instalar o controlo de código ApexSQL, basta carregar com o botão direito na base de dados que deseja controlar a versão e navegar para o sub-menu de controlo de código ApexSQL em SSMS. Clique no banco de Dados Link para a opção de controle de origem, selecione o sistema de controle de origem e o modelo de desenvolvimento. Depois disso, você precisará fornecer a informação de log-in e o texto do repositório para o sistema de controle de origem que você escolheu.

Pode ler este artigo para mais informações: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Faço-o gravando scripts create/update e um script que gera sampledata.

Também tínhamos alguns scripts que o devs poderia usar para reiniciar o seu db local para a versão actual com um único comando.

Eu normalmente construo um script SQL para cada alteração que faço, e outro para reverter essas alterações, e manter esses scripts sob controle de versão.

Então temos um meio de criar um novo banco de dados atualizado a pedido, e pode facilmente mover-se entre revisões. Cada vez que fazemos um lançamento, juntamos os scripts (requer um pouco de trabalho manual, mas raramente é realmente difícil) então também temos um conjunto de scripts que podem converter entre versões.

Eu uso o SQL cria scripts exportados a partir do MySQL Workbech, então usando a funcionalidade "Exportar SQL ALTER" deles eu acabo com uma série de scripts criar(numerados, é claro) e os scripts alter que podem aplicar as mudanças entre eles.

3.- Exportar o programa SQL alterar Normalmente você teria que escrever as declarações da tabela ALTER à mão agora, refletindo suas alterações que você fez ao modelo. Mas podes ser inteligente e deixar o Workbench fazer o trabalho duro por ti. Basta seleccionar o ficheiro - > Exportar - > Engenheiro avançado SQL alterar o programa ... do menu principal.

Isto pedir-lhe-á para indicar o ficheiro SQL criar com o qual o modelo actual deve ser comparado.

Seleccione o script SQL CREATE do Passo 1. A ferramenta irá então gerar o script de tabela ALTER para você e você pode executar este script contra o seu banco de dados para trazê-lo até a data.

Você pode fazer isto usando o navegador de consultas MySQL ou o cliente mysql.Voilà! O seu modelo e base de dados foram sincronizado!

Fonte: MySQL Workbench Community Edition: Guide to Schema Synchronization

Todos estes scripts, claro, estão dentro sob controle de versão.

Por exemplo, para ser útil, a sua aplicação pode precisar disto na instalação:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Teríamos um ficheiro chamado currency.sql sob subversion. Como um passo manual no processo de construção, comparamos a moeda anterior.sql para o mais recente e escrever um script de atualização.

Nós controlamos a versão e a fonte de tudo o que rodeia as nossas bases de dados:

• DDL (criar e alterar)
• DML (dados de referência, códigos, etc.)
• alterações do modelo de dados (utilizando ERwin ou ER/Studio)
• alterações da configuração da Base de dados (permissões, objectos de segurança, alterações gerais da configuração)

Eu acredito que cada DB deve estar sob controle de fonte, e os desenvolvedores devem ter uma maneira fácil de criar seu banco de dados local a partir do zero. Inspirado pelo Visual Studio para profissionais de banco de dados, eu criei uma ferramenta de código aberto que scripts bases de dados MS SQL, e fornece e uma maneira fácil de implementá-los para o seu motor DB local. Tentar http://dbsourcetools.codeplex.com / . Divertir, - Nata.

Http://www.red-gate.com/products/SQL_Source_Control/index.htm

Uma solução alternativa Visual Studio é ReadyRoll , que é implementada como um subtipo do projecto de base de dados SSDT. Isto tem uma abordagem baseada em migrações, que é mais adequada aos requisitos de automação das equipes DevOps.

USO SchemaBank para controlo de versões todas as alterações do esquema da minha base de dados:

A partir do primeiro dia, importei o meu esquema de db para ele.
• comecei a mudar o meu esquema usando um navegador web (porque são baseados em SaaS / cloud)
• Quando eu quero atualizar o meu servidor db, eu gerar o script de mudança (SQL) a partir dele e aplicar para o db. No Schemabank, eles me mandatam para enviar meu trabalho como uma versão antes que eu possa gerar um script de atualização. Eu gosto deste tipo de pratique para que eu possa sempre rastrear quando preciso.

Uma ferramenta de desenho de esquemas baseada na web com controlo de versões e gestão de mudanças.

Eu controlo o esquema da base de dados programando todos os objectos (definições de tabelas, índices, procedimentos armazenados, etc.). Mas, quanto aos dados em si, basta confiar em backups regulares. Isto garante que todas as mudanças estruturais são capturadas com o histórico de revisão adequado, mas não sobrecarrega o banco de dados cada vez que os dados mudam.

Lotes e lotes de testes é feito antes que os scripts são executados no ambiente ao vivo, então "oopsies" só acontece, em geral, em bases de dados de desenvolvimento.

Usei a ferramenta dbdeploy da ThoughtWorks at http://dbdeploy.com / . incentiva a utilização de programas de migração. A cada lançamento, consolidamos os scripts de mudança em um único arquivo para facilitar a compreensão e permitir que o DBAs "abençoe" as mudanças.

Este sempre foi um grande aborrecimento para mim também - parece que é muito fácil fazer uma mudança rápida em seu banco de dados de desenvolvimento, salvá-lo (esquecendo de salvar um script de mudança), e então você está preso. Você poderia desfazer o que você acabou de fazer e refazê-lo para criar o script de mudança, ou escrevê-lo do zero, se você quiser, claro, também, embora isso é muito tempo gasto escrevendo scripts.

Uma ferramenta que eu usei no passado que ajudou com isso alguns é SQL Delta. Ele irá mostrar-lhe as diferenças entre duas bases de dados (SQL server/Oracle I believe) e gerar todos os scripts de mudança necessários para migrar A->B. outra coisa boa que ele faz é mostrar todas as diferenças entre o conteúdo do banco de dados entre o DB de produção (ou teste) e o seu DB de desenvolvimento. Uma vez que cada vez mais aplicativos armazenam configuração e estado que é crucial para a sua execução em tabelas de banco de dados, pode ser uma dor real ter scripts de mudança que remover, adicionar e alterar as linhas apropriadas. Delta SQL mostra as linhas na base de dados tal como iriam procurar numa ferramenta de diferenças - alterada, adicionada, apagada.

O RedGate é óptimo, geramos novos instantâneos quando são feitas alterações de bases de dados (um pequeno ficheiro binário) e mantemos esse ficheiro nos projectos como um recurso. Sempre que precisamos atualizar o banco de dados, usamos o kit de ferramentas do RedGate para atualizar o banco de dados, bem como ser capaz de criar novos bancos de dados a partir dos vazios.