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
