Eu pensei e li muito sobre este tópico. Este é um tópico amplo de controle de configuração e estratégia de gerenciamento de mudanças. O CMMI tem um domínio neste tópico. Mesmo em empresas que possuem uma acreditação do CMMI 3-5, às vezes elas não controlam seus bancos de dados de versão.
Esta pergunta deve ser respondida, mantendo em mente as seguintes restrições .
- Você tem um detentor e cada DDL é executado por esse detentor.
- Outras pessoas têm capacidade de executar instruções DDL.
- Você só precisa registrar quais alterações foram feitas, mas não precisa comparar grandes diferenças.
- O design do seu banco de dados é feito por meio de uma ferramenta externa e depois publicado no banco de dados. Essa ferramenta externa pode ser scripts DDL no controle de origem mesmo. Mas o ponto principal é que você controla a fonte e publica no banco de dados.
- Você não precisa conhecer alterações instantâneas, mas de tempos em tempos: ou seja, a cada hora, diariamente.
- Você tem uma estrutura de servidor definida: Desenvolvimento, Teste, Produção. E uma boa estratégia de teste.
resposta 1
- se 1, 4,6 for verdadeiro, você poderá usar um controle de fonte externa. Por exemplo
- O Embercadero possui uma ferramenta de gerenciamento de alterações de banco de dados ( http://www.embarcadero.com/products/db-change-manager-xe ). Que tem capacidade de fazer engenharia reversa de um banco de dados (Oracle) e colocá-lo em seu controle de origem. Em seguida, qualquer número de desenvolvedores, dba, pode acessar esse esquema e fazer alterações nele.
- O Oracle SQL Designer é semelhante a essa abordagem.
- Colocando você cria scripts de tabela para controle de origem (svn, mercurial etc) e os mantém também a mesma coisa.
- http://www.liquibase.org é uma abordagem automatizada acima.
- Escrevi um gerador de código que gerava instruções DAL (Data Access Layer), DDL (Create Table). Nós os colocamos no controle de origem e mantemos lá. Eu acho que uma solução dedicada como o liquibase pode funcionar melhor.
Essa abordagem funciona bem se tiver 6. Você coloca instruções DDL, que também é um código, no controle de origem e as mantém. Ninguém mudará os servidores de teste e produção sem a devida consideração.
Desvantagens é que, se você fizer alguma alteração nos servidores de produção ou teste, por qualquer motivo, uma correção rápida de bug, alteração da chave primária etc. Uma vez que realmente o servidor de desenvolvimento é a sua VERDADEIRA TERRA. Não o contrário.
Essa é uma abordagem muito orientada ao desenvolvedor. Mas quando você desenvolve um novo módulo, ele funciona muito bem.
Resposta 2
- se 1 e 6 são verdadeiros:
Uma abordagem semelhante à resposta 1 é manter um servidor de desenvolvimento. Todo mundo usa isso muda. Do que quando chega a hora de atualizar. Você usa uma ferramenta de comparação de banco de dados. Obtenha-os como scripts, coloque-os sob controle de origem.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
A diferença entre a resposta 1 e a resposta 2 é que, na resposta 1, você coleta instruções DDL para todo o banco de dados e as armazena. Na resposta 2, você precisa armazenar todas as versões da mudança.
- Começar
- V1
- V2
- V3
- ...
Se você colocar uma coluna em uma tabela e depois decidir removê-la. Seus scripts mostrarão isso na resposta2, enquanto na resposta1 você verá apenas a última versão. E você precisa comparar V2 e V1 para ver as diferenças. Pessoalmente, eu gosto mais da resposta 1, pois posso comparar facilmente Start e V3, V1 e V3. Na resposta 2, preciso procurar todas as alterações. Também na resposta 2, o script no controle de origem tende a ser um script complexo e complexo. Difícil de encontrar informações.
Resposta 3
Se 3 for verdadeiro. Observe que, nessa situação, você não possui restrição 6, ou seja: não possui servidores de desenvolvimento, teste e produto. Apenas servidor de produção. Você pode usar gatilhos DDL para registrar quais alterações foram feitas. Isso é usado principalmente para desencorajar as pessoas a abusar de suas concessões de DDL. Se ocorrer algum problema, você pode ser o responsável. Para que isso funcione, todas as pessoas devem se conectar à sua conta de usuário e a conta do Aplicativo não deve ter nenhuma concessão de DDL. Como todo desenvolvedor conhece a conta do Aplicativo e pode usá-lo.
Resposta 4
Se você possui 3 e 5. Observe que nessa situação você não possui uma restrição 6, ou seja: você não possui servidores de Desenvolvimento, Teste e Produto. Apenas servidor de produção. Em vez de acionar para armazenar alterações. Você usa uma ferramenta externa para localizar alterações e armazenar scripts DDL no controle de origem.
Se essa ferramenta tiver a capacidade de registrar quem fez alterações, seria útil. Observe que nesta solução você perde DDL extra, feito em intervalos.