[firebase-br] Controle de versão dos objetos do Firebird

[Marcio Toloi]

Tá certo!  Vou dar uma estudada no DDL triggers do FB 3... (valeu Cantu).

Armazenar as alterações da estrutura de uma tabela seria muito interessante
pra nós aqui na empresa.

Não sei se vocês já passaram por isso, mas muitas vezes quando nossa equipe
de TI se reúne para discutir as alterações em regras de negócio, muitas
dúvidas surgem quando nos questionamos sobre fatos antigos... coisas do
tipo: "Quando que este campo passou a ser NOT NULL?", ou "Porque esta
chave-estrangeira foi dropada?... quando ela foi dropada?", ou "Desde
quando esta trigger está desativada?".



Agradeço a atenção de vocês!


Abraço.


Marcio Henrique Toloi
marcio.toloi em gmail.com





Em 17 de novembro de 2015 17:14, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Eu não sei se seria possível, mas se tiver a fim de experimentar você pode
> exibir as tabelas de sistema, encontrar a tabela rdb$procedures e criar uma
> trigger before insert/update/delete para registrar noutra tabela ou banco o
> codigo anterior de sua procedure. O mesmo se repetiria para outros objetos,
> menos tabelas porque elas não tem um codigo SQL, uma trigger na tabela de
> sistema que controla os campos seria individual, 1 registro=1 campo..
> Nunca testei isso, mas se funcionar atente-se que essas triggers não serão
> permanentes, se você restaurar o banco, suas triggers em cima dessas
> tabelas de sistema serão perdidas.
>
> Em 16 de novembro de 2015 14:45, Marcio Toloi <marcio.toloi em gmail.com>
> escreveu:
>
> > Olá pessoal.
> >
> > Este é meu primeiro post na lista, mas já acompanho vocês há alguns
> anos...
> >
> > Alguém da lista por um acaso conhece uma maneira (ou ferramenta) para
> > controlar o histórico de alterações dos objetos do Firebird?
> >
> > Por exemplo: Se eu altero uma Stored Procedure no banco, o novo
> > código-fonte dela (ddl) será atualizado na coluna *rdb$procedure_source*
> na
> > tabela *rdb$procedures*. Neste caso eu conseguiria através de uma trigger
> > armazenar as várias versões do código-fonte. Mas o que fazer quando
> > alteramos as colunas de uma tabela? Seria possível rastrear esta
> alteração?
> >
> > Para ilustrar um pouco essa ideia: - Eu trabalho como Analista de
> Sistemas
> > aqui na empresa há 10 anos, e grande parte das minhas atividades é fazer
> > manutenções em objetos do banco. Nós aqui temos o hábito de registrar
> essas
> > alterações em forma de documentação de tarefas, e também salvamos o novo
> > código-fonte em um servidor SVN.
> >
> > A empresa aqui trabalha com a mesma base de dados Firebird há mais de 16
> > anos. Desde então, esta base já passou pelo Interbase, depois migramos
> para
> > o Firebird 1.5, depois para o Firebird 2.1.... e estamos prestes a migrar
> > para o Firebird 2.5.
> >
> > Ao longo de todos estes anos, inúmeras foram as alterações em procedures,
> > tables, triggers, etc (por pessoas diferentes). E seria muito
> interessante
> > que o Firebird registrasse para cada objeto da base algo como: "creation
> > date" e "last modification date", além do "Description" que já existe.
> >
> > Para as tabelas, seria interessante que ele registrasse quando uma
> "foreign
> > key" foi criada ou dropada... quando que uma "primary key" foi criada...
> > etc.
> >
> > Alguém já fez isso? Ou precisou fazer um controle parecido? :D
> >
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>