Em 25 de agosto de 2016 15:10, Fabiano Machado Dias <fabi...@wolaksistemas.com.br> escreveu:
> 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? Sim, entendo. Quando você envolve outras entidades certamente é inevitável consultar outras tabelas. Neste caso provavelmente não haveria ganho ou perda entre as duas abordagens (chaves compostas naturais ou artificiais únicas). >> 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. Depende de cada caso. Ainda assim, um índice "grande" por tabela não representa muito espaço adicional. >> > 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) Este caso da UTFPR é um sistema pequeno, o banco de dados não chega a 2 GB hoje. Atendo clientes com bases da ordem de 1 TB ou mais, e lhe garanto que quanto maior o tamanho, maior o tombo. As inconsistências geradas pelo uso de chaves artificiais, muito semelhantes aos que citei no caso do meu sistema, são constantes. E tem mais: se desde o início o sistema for concebido da forma correta, qual o problema para o cliente em se planejar? >> > 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. Isso é verdade. Cada vez mais estão ficando preguiçosos e muito "NoSQL". A resposta que sempre dou quando participo de um projeto assim: ou o desenvolvedor/programador aprende SQL básico, ou está fora do projeto. De qualquer forma pode haver alguém para criar as consultas, a minha empresa mesmo trabalha em projetos prestando consultoria e apoio aos desenvolvedores neste sentido. Você tem que escolher entre um sistema bem feito para agradar os clientes ou agradar os programadores. Eu prefiro a primeira opção :) >> 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 Sim, entendi. Concordo que muitas vezes há tantas "buchas" já pela metade que não temos como mudar tudo. Mas a ideia central é começar já fazendo certo, com chaves compostas naturais. TIAGO J. ADAMI _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
