Pergunta

Eu estou tentando implementar o controle de fonte de banco de dados.

a ferramenta eu preciso deve criar um arquivo separado para cada objeto no banco de dados, de preferência organizados em pastas, como

procedimentos armazenados funções Visualizações tabelas

e seria ótimo ser capaz de também despejar os resultados de determinadas consultas, a fim de acompanhar as alterações de dados em várias tabelas de configuração ...

Gostaria de saber se há já é uma ferramenta que pode lidar com esse tipo de coisa ...

-

apenas para limpar algumas coisas ...

Eu já estou usando delta SQL para lidar com os scripts de atualização ...

Eu gostaria de ter scripts do DB, a fim de utilizar o Subversion, para que eu possa rastrear o que os objetos que mudou com cada commit, sem ter que estudar os scripts de atualização ...

Estou desenvolvendo um roteiro agradável vb com o SQL Distributed Management Objects (SQL-DMO), eu vou te dizer como vai ser ...

boa do que em ter minha própria solução, é que eu também inclui as saídas de consultas ou execução do procedimento armazenado, para rastrear as mudanças em certas tabelas, configuração do servidor, o crescimento da base de dados, bem, tudo o que eu posso despejar a um arquivo de texto ...

Nenhuma solução correta

Outras dicas

Eu uso ScriptDB exatamente para este fim. A única coisa que eu tinha que mudar era remover a data de scripting nos arquivos gerados. Caso contrário, os arquivos são sempre marcadas como mudou no Subversion.

Aqui está o uso de lote I. cliente SvnClient é a ferramenta de codeplex svncompletesync.codeplex.com , o check-in de todos os arquivos de uma pasta para a subversão. :

svn checkout "http://svn/myproject" D:\Projekte\db_svn\myproject

ScriptDB "D:\temp\scriptdb" myserver mydb mylogin mypwd

del "D:\Projekte\db_svn\myproject\Schema Objects\\*.sql" /q /s

xcopy "D:\temp\scriptdb\myserver\mydb\Schema Objects\\*.sql" "D:\Projekte\db_svn\myproject\Schema Objects" /e /y /i

svnclient "D:\Projekte\db_svn\myproject" -m "commit durch svncompletesync"

Se eu entendi corretamente, você precisa de duas coisas: primeiro você precisa para gerar os scripts de metadados de banco de dados (tabelas, vistas, procedimentos armazenados, etc), e uma vez feito isso, você precisará usar algum tipo de metodologia consistente para o script de versão.

Se você já tem o seu metadat e os dados no banco de dados, eu não ver o que iria impedi-lo de usando SQL Management Studio (ou SQL Enterprise Manager) para gerar scripts a partir de objetos de banco de dados: consulte Como gerar um script (SQL Server Management Studio ) . Isso deve funcionar para o SQL Server 2000, 2005, etc. Tenha em mente que você pode personalizar as configurações de geração de script, por exemplo, em vez de um grande roteiro, você pode usar scripts individuais para cada objeto. Pode ser necessário para escrever alguns scripts para tabelas preencher com dados (não tenho certeza se a extração de dados apoios do assistente).

Uma vez que você tem os scripts, você provavelmente terá de distribuí-los manualmente entre pastas específicas e quando isso é feito, você deve estar pronto para verificá-los no controle de origem. Deste ponto em diante você precisa descobrir a metodologia para os seguintes instalações de banco de dados, atualizações e reparos. Esta é uma tarefa bastante complexa, cobertura que iria demorar mais do que uma resposta simples. Se você estiver interessado em opções possíveis, verificar o meu instalador de banco de dados revisto post que menciona uma série abordagens e referências vários artigos abordando banco de dados de versões (desculpe para a auto-promoção, mas eu não quero repetir a mesma informação).

A maioria das ferramentas neste campo não são livres, mas há um projeto open source, ScriptDB , que podem atender às suas necessidades para scripts de geração.

Isso não vai resolver o problema de como aplicar os scripts para o banco de dados na ordem certa -. Se você não quiser pagar, você pode ter que improvisar o seu próprio

Você pode tentar Wizardby , que não é exatamente o que você está pedindo , mas ainda pode ajudá-lo a lidar com a gestão da mudança de banco de dados. Ele pode fazer engenharia reversa seu esquema de banco de dados (bem, um subconjunto dele) e em seguida, escrever os chamados "migrações" em uma DSL especial independente de plataforma:

version 20090331140131:
    oxite_FileResource:
        FileResourceID type => PK, primary-key => true
        SiteID type => Guid, nullable => false
        FileResourceName type => LongName
        CreatorUserID references => oxite_User
        Data type => Binary
        ContentType type => AnsiString, length => 25, nullable => false
        Path type => String, length => 1000, nullable => false
        State type => Byte, nullable => false
        CreatedDate type => DateTime, nullable => false
        ModifiedDate type => DateTime, nullable => false 

    oxite_UserFileResourceRelationship:
        UserID references => oxite_User
        FileResourceID references => oxite_FileResource:
            add index unique => true

        index "" columns => [UserID, FileResourceID], unique => true, clustered => true
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top