Controle do objetos de banco de dados

Em uma empresa que trabalhei anteriormente, também tinhamos esse problema.

Para resolver isso, decidimos fazer versões do banco. Por exemplo:

iamos alterando o banco de desenvolvimento, sempre com scripts SQL com controle de versão, ai decidiamos fechar uma versão da aplicação, fechavamos também a do banco. E salvavamos backups das versões anteriores, pro caso de precisarmos voltar para a versão anterior.

Depois de fechada a versão, passavamos para o banco de homologação (rodavamos todos os scripts SQL da nova versão) onde eram realizados os testes, com os testes aprovados passavamos para o ambiente de Produção.

não é um processo muito bom, mas a equipe era bem pequena (6 programadores) e o processo funcionava bem.

Tem ferramentas de comparação entre bancos, uma que conheço é o DBComparer, que compara as bases e gera os scripts sql das diferenças.

Ah!

Eu tenho um agravante tambem.
Utilizamos Sybase

ezambomsantana:

Em uma empresa que trabalhei anteriormente, também tinhamos esse problema.

Para resolver isso, decidimos fazer versões do banco. Por exemplo:

iamos alterando o banco de desenvolvimento, sempre com scripts SQL com controle de versão, ai decidiamos fechar uma versão da aplicação, fechavamos também a do banco. E salvavamos backups das versões anteriores, pro caso de precisarmos voltar para a versão anterior.

Depois de fechada a versão, passavamos para o banco de homologação (rodavamos todos os scripts SQL da nova versão) onde eram realizados os testes, com os testes aprovados passavamos para o ambiente de Produção.

não é um processo muito bom, mas a equipe era bem pequena (6 programadores) e o processo funcionava bem.

Onde trabalhei anteriormente tínhamos um controle idêntico ao apontado por você.
Até que funcionava bem por ser uma equipe pequena também (e uma empresa bem pequena).
Começamos a ter problemas quando o cvs dava uns merges esquisitos nesses arquivos sql, daí fizemos um arquivo pra cada desenvolvedor pra cada versão, mas ai teve outro problema de parte de um script de um ter que rodar antes do script do outro e assim por diante, que dava dor de cabeça quando ia implantar. Mas como a equipe é pequena acabava se saindo bem.

Vou pesquisar como fazem por aqui, com certeza deve ser algo mais inteligente…

Abraços!

Já experimentou usar algo como dbdeploy? É o que usamos por aqui para rastrear versões do banco de dados. É inspirado na abordagem de Migrations do Ruby on Rails e se baseia numa tabela de CHANGELOG para indicar a versão que o db está rodando.

Muito interessante, valeu pela dica.
Analisando-o.