2016-08-25 14:46 GMT-03:00 Fabiano Machado Dias <[email protected]>: > 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
‘Geralmente‘ é muito impreciso. Pode significar que você economiza, por exemplo, apenas 1% das junções ou 49% delas. Mesmo 1% pode ser significativo nalgumas circunstâncias, mas a verdade geralmente é bem maior. > 2 - Os índices ficam bem maiores Sim, mas há menos índices. Isso geralmente é muito importante, mais do que haver índices menores. > 3 - Vc tem uma redundância de informações e maior consumo de espaço Isso geralmente não é importante, a menos que você tenha alguma situação muito particular. > 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. O tamanho da instrução é irrelevante. Escrita, novamente, economiza a quantidade de índices. > O sistema em questão que eu citei anteriormente tem todos esses problemas e > hoje é um verdadeiro elefante branco. Sem mais informações é difícil afirmar qualquer coisa, mas eu suspeitaria de outros problemas que não esse. Eu chutaria falta de normalização e de restrições declarativas de integridade (consistência feita via código aplicativo procedural). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:[email protected] +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:[email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
