No trabalho, estamos usando Oracle e C#/ASP.net para lidar com o site de um cliente. Esse site é de grande escala, então o banco de dados émuitogrande.
Usamos Perforce para nosso controle de versão e criamos ou substituímos scripts para casos do FogBugz sempre que um banco de dados muda, o que tem sido bom até agora, já que estamos em um ponto onde cinco desenvolvedores estão trabalhando em cinco expansões para o sistema, cada uma em uma ramificação separada do Perforce. Infelizmente, não podemos obter bancos de dados duplicados, devido ao tamanho do banco de dados, então todos ainda trabalham no mesmo. Obviamente, isso é a causa de problemas: há apenas dez minutos tivemos um problema em que uma alteração no procedimento armazenado de uma ramificação se propagou para o servidor de pré-produção e causou um grande número de travamentos para os testadores. Idealmente, gostaríamos de ter uma maneira de rastrear essas mudanças sem ter que acompanhá-las manualmente através do FogBugz.
Minha pergunta é: como vocês lidam com essa situação? Tenho certeza de que agora deve haver uma boa maneira de lidar com o controle de versão, ou pelo menos rastrear alterações, em um banco de dados Oracle.
Responder1
11gR2 introduziu o conceito de edição de código, se uma atualização de banco de dados for viável.
O seu esquema de dados é igual ao esquema de código? Pode ser uma boa ideia separá-los. Dessa forma, você pode ter o mesmo conjunto de tabelas de banco de dados, mas diferentes conjuntos de esquemas de código. Então, um projeto pode usar um esquema de código e outro pode usar um segundo esquema.
Contanto que você esteja vinculado a um único conjunto de dados, terá restrições. Se um projeto espera um valor de único caractere, mas outro o expande para dois caracteres, você pode esperar problemas.