Em 25 de agosto de 2016 14:46, Fabiano Machado Dias
<fabi...@wolaksistemas.com.br> escreveu:
> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
> ou "neta" da tabela.
>
> Mas assim, no que eu vi, na prática é o seguinte:
>
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai
> acontecer igual

Discordo. Se suas chaves naturais estão bem definidas, na grande
maioria das vezes é suficiente. Por exemplo: a consulta mais
recorrente sobre a tabela RESERVA é listar todas as reservas do campus
'DV' e do usuário logado no sistema pelo campo matricula_usuario. Não
preciso de JOIN para fazer isso com o "modelo natural".

Esta declaração só é verdadeira no caso de relatórios que busquem mais
informações, mas neste caso você pode eliminar o JOIN com tabelas
intermediárias, tornando o modelo com chaves naturais ainda mais
eficiente.

> 2 - Os índices ficam bem maiores

Apenas "O" índice da chave primária fica maior. Você poderá ter
índices auxiliares que terão o mesmo tamanho.

> 3 - Vc tem uma redundância de informações e maior consumo de espaço

Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
de 20% com os testes que fiz. Contrabalanceando, o desempenho das
consultas ficou muito mais rápido.

> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
> tamanha da instrução.
>

A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
adicional na escrita, mas isso é irrelevante em relação aos benefícios
obtidos, principalmente no desempenho das consultas.

Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
chaves naturais, pela minha experiência a necessidade de usar tabelas
intermediárias diminui muito. Dificilmente uma consulta mais complexa
do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.



TIAGO J. ADAMI
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Reply via email to