> > 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. > > Quando vc varre uma tabela de itens de uma nota, vc está buscando dados do item né? E a programação de entrega desse item? Não está em outra tabela ainda? Entende o que quero dizer?
> > 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. > Mesmo exemplo acima. Nota/item/programacao_entrega - vejo o tamanho desses índices em um caso real. > > > 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. > Não sei o tamanho das bases que trabalha, mas pra mim é um problema em vários clientes atualmente (bases na case de alguns teras) > > > 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. > Olha, hoje em dia eu vejo cada vez menos desenvolvedores com conhecimentos de SQL, quando eu mostro uma consulta com vários join's vários arrepiam os cabelos, mas sim é irrelevante quando se sabe o que está fazendo. > > 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. > Não estou sendo contra as chaves naturais, mas acho que vc pode obter o melhor sabendo usar os 2 cenários > > > > TIAGO J. ADAMI > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
