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

[Jancarlos Martins]

​Não é mais fácil ​extrair o Metadata e gravar em servidor de repositórios.
Por exemplo Subversion.


até

Jancarlos Martins


Em 18 de novembro de 2015 15:10, Alexandre <camilo em apollosistemas.com.br>
escreveu:

> Marcio, aqui na empresa, esse tipo de informação  "
>
> "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?".
>
> " colocamos tudo no controle de versão do software (svn), e colocando
> algumas palavras chaves nos comentários, fica bem tranquilo de encontrar
> quando necessário. É uma ideia
>
>
> Alexandre Camilo.
>
>
> Em 18/11/2015 13:52, Marcio Toloi escreveu:
>
>> 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
>>>
>>> ______________________________________________
>> 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
>>
>>
> --
>
> Alexandre Camilo
> +55 27 3233-4143
>
>
>
> ______________________________________________
> 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
>