[firebase-br] ac/Cantu integridade refencial declarativaxtriggers?

[Carlos Fernando von Groll]

Participo da opinião do colega Josauro, tanto pelos motivos que justificam sua
posição, como pelo que vou tentar explanar:

Todas as tabelas dos bancos que modelo utilizam como PK um INTEGER.

Agora vem a questão...

Tomemos como exemplo uma tabela de produtos, na qual é indicado também o
identificador do fornecedor e/ou fabricante.

Agora suponhamos que seja necessário uma outra tabela, na qual seja especificada a
composição de determinados produtos, com components do mesmo fornecedor e/ou
fabricante do produto composto. Para assegurar que um produto seja composto de
outros do mesmo fabricante e/ou fornecedor, e utilizando apenas FK, seria
necessário criar uma UNIQUE KEY na tabela de produtos, composta do identificador do
fornecedor e/ou fabricante e do identificador do item propriamente dito, e fazer a
referência na tabela de compostos. Para isso se torna necessário incluir também, na
tabela de compostos, o identificador do fornecedor e/ou fabricante, o que é
redundante. Tudo bem! Isso funciona. E funcionaria em tantos níveis de integridade
quantos fossem necessários. Só que, no mínimo, uma tabela no quinto nível de
integridade, teria cinco campos chave, além da PK.

A única maneira de eliminar essa redundância, seria através de triggers.

Então, um pouco aos gregos... outro tanto aos troianos...

Cada caso é um caso!

Não sei se consegui vender meu peixe com clareza.



> Sem problemas Renato, acho valido todas as opniões a minha estou formando por
> conhecimento adquirido com os colegas e leituras.
> O que ocorre é que FK cria um indice a mais em seu banco de dados e se vc tiver que
> manter um indice so para fazer essa integridade, tenho lido que não vale a pena
> pelo fato de que indice deve se criar o minimo possivel, e sempre com o bojetivo
> que sejam necessario onde as consultas sejam otimizadas com ele, usando se mutio as
> FK podemos criar indice duplicados o que é uma pessima coisa para o FB.
> Criar uma FK para fazer referencia a uma tabela onde a incidencia de registros
> duplicados seja muito grande, não adiantara nada o indice, imagine o cadastro de
> clientes, com FK para uma tabela de Pais, onde todos estao como Brasil, o que
> adiantara o indice ? so peso de manutenção.
> Alem de que FK engessam um pouco o BD na hora de alguma necessidade, de manutenção
> nos dados, trigger podem ser ativada/desativadas.
>
> Entao como gosto das FK e gosto das trigger, faço os dois usando conforme disse,
> quando for util para agilizar a busca de dados uso FK, se for so para validação
> faço uma trigger. Fiquei com poucas FK no BD, e com uma boa administração das
> minhas integridades.
> (Logico cada um tira suas conclusões, eu mesmo, ja usei muito uma e pouco outra dos
> dois lados, hoje achei o equilibrio para minha forma de desenvolvimento.)
>
> Grande abraço e me posicione a respeito de suas idéias.
>
> Josauro S.J.
> Diretor
> josauro em casasoft.inf.br
> ----- Original Message -----
> From: Renato Bermudo
> To: FireBase
> Sent: Wednesday, January 05, 2005 6:02 PM
> Subject: Re: [firebase-br] ac/Cantu integridade refencial declarativaxtriggers?
>
>
> Caro Josauro, vc diz na sua opinião que não se deve usar FK apenas como
> integridade referencial? Por que não?
> No meu entender, uma das garantias de manter a integridade dos dados é via
> FK e não correr riscos de escrever uma trigger errada e acabar fazendo uma
> besteira no banco.
> Não leve isso como uma crítica, eu faço da forma que citei e gostaria de
> saber o motivo que se leva em criar uma trigger que vai fazer o mesmo
> trabalho de um FK.
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>
>