[firebase-br] Integridade referencial

[Éder Monteiro do Nascimento]

É isso, se existem regras, na maioria das vezes, é interessante que estejam
no banco, já que ele é a fronteira final. Tipo, se tenho algo que pode
bagunçar, se o banco entender, é melhor para a manutenção dos dados. Tipo,
acessei o banco e rodei um update, se o banco não conhece a regra, um
update errado pode bagunçar muito, ou um delete, insert etc.







*Éder Monteiro do Nascimento*

Programador

Fator Sistemas & Consultoria

e-mail: *eder.nascimento_fator em hotmail.com <eder.nascimento em hotmail.com>*

http://fatorsistemas.com.br


Em qua., 29 de jul. de 2020 às 11:20, Gustavo Novaes <gutonovaes19 em gmail.com>
escreveu:

> Eder,
> Não me preocupei em explicar direito as regras atuais, meu foco era saber o
> que seria mais indicado pois havia lido sobre integridade referencial via
> triggers;
> Tenho um processo para excluir empregados junto com seus históricos,
> gerando uma cópia dos dados. Só assim pode ser excluído. Não existe
> exclusão de empresa que ainda tenha empregado associado a ela. Também há um
> processo para mudar empregados entre filiais.
> Então, só excluir filial sem empregados (restringir). O mesmo para  Empresa
> em relação a filial.
> Excluir colaboradores e seus registros (cascade com exportação).
> Espero não ter esquecido de nada na explicação.
>
> O cenário acima é ficticio, similar ao real. No real tenho um complicador,
> chaves estrangeiras compostas. Num dos textos do Jason ele critica isso, se
> entendi, um modelo inadequado. Estou numa migração de banco, tentando
> reescrever o mínimo possível (desde que não piore o produto). Já tive que
> refazer algumas coisas, no entanto; reescrever.
> Preciso reler sobre o assunto. Aceito dicas e críticas, sem problema.
>
> *Gustavo Novaes *
>
>
>
>
> Em qua., 29 de jul. de 2020 às 10:39, Éder Monteiro do Nascimento <
> fator em aliancati.com> escreveu:
>
> > Pelo que ele colocou, tem uma diferença;
> > Se ele for excluir uma empresa, ela tem que excluir empregados, mas se o
> > empregado tiver histórico, não é para excluir.
> > Se ele for excluir um funcionário, é para excluir o histórico.
> > Se de fato for isso, vc não tem como fazer (pelo menos não vejo como) de
> > forma direta. São dois comportamentos muito divergentes.
> > Uma forma de fazer é travar por exemplo via trigguer, usando uma variável
> > de transação, e deixando a fk como cascate.
> >
> > Mas por que desse comportamento?
> >
> >
> >
> >
> >
> > *Éder Monteiro do Nascimento*
> >
> > Programador
> >
> > Fator Sistemas & Consultoria
> >
> > e-mail: *eder.nascimento_fator em hotmail.com <eder.nascimento em hotmail.com
> >*
> >
> > http://fatorsistemas.com.br
> >
> >
> > Em qua., 29 de jul. de 2020 às 09:56, Carlos H. Cantu <
> > listas em warmboot.com.br> escreveu:
> >
> > > Não precisa de trigger. Nas FKs onde vc deseja impedir a remoção do
> > > pai se existir filhos, vc omite a clausula ON DELETE CASCADE, e aí o
> > > próprio Firebird vai impedir que o "pai" seja excluído caso ele tenha
> > > filhos.
> > >
> > > []s
> > > Carlos H. Cantu
> > > eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
> > > www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
> > >
> > > GN> Bom dia,
> > > GN> Li um artigo no site firebase com considerações sobre a integridade
> > > GN> referencial declarativa x triggers.
> > > GN> Tenho registros PAI que não podem ser excluídos caso tenha
> registros
> > > filhos
> > > GN> e alguns casos de exclusão em cascata.
> > > GN> Exemplo: Empresa, filial, empregado, "informações sobre o
> empregado".
> > > GN> Posso excluir do banco empresas e filiais que não tenham nenhum
> > > empregado
> > > GN> relacionado.
> > > GN> Se excluir um empregado, devo excluir seu histórico.
> > > GN> Fazia esse controle via código no DELPHI com o paradox.
> > > GN> Na migração , gerei o script sem os FK (não existiam no paradox).
> > > GN> Agora seria o momento de decidir manter como era ou:
> > > GN> - criar FK com exclusão em cascata
> > > GN> - criar triggers que verificam e impedem excluir um empregado que
> > tenha
> > > GN> históricos (históricos considere mais de uma tabela com propósitos
> > > GN> diferentes).
> > >
> > >
> > >
> > > GN> *Gustavo Novaes *
> > > GN> ______________________________________________
> > > GN> FireBase-BR (www.firebase.com.br) - Hospedado em
> www.locador.com.br
> > > GN> Para saber como gerenciar/excluir seu cadastro na lista, use:
> > > GN> http://www.firebase.com.br/fb/artigo.php?id=1107
> > > GN> Para consultar mensagens antigas:
> > > GN> 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
> > >
> > ______________________________________________
> > 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
>