Em 28 de abril de 2015 20:05, Matheus Saraiva <matheus.sara...@gmail.com> escreveu: >>> E se o servidor for modesto? Se o espaço de armazenamento for um >>> requisito crítico? > >>Tire a artificial, se for o caso. Mas lembre-se da máxima: otimização >>precoce é raiz de toda sorte de males. > > Quanto ao desempenho de JOINS realmente nuca testei, mas acho que quanto a > espaço em disco ao usar chaves naturais compostas para relacionamento é algo > inevitavelmente mais custoso, já que teria-se que replicar os mesmo campos > que compõe a chave primária na tabela que se relacionaria com ela.
Isso só no caso em que a chave primária realmente é ‘replicada’ como chave estrangeira em outras relações. Não é nem de longe o caso geral. > Acho que para esse caso, eu usaria chaves artificiais para o relacionamento > e criaria UNIQUEs para garantir a unicidade. É uma alternativa válida, quando necessário. Como sempre digo, o pior problema das ‘chaves’ artificiais é quando se confia nelas a ponto de não se declararem chaves naturais. Mas, entre você ter de ter um atributo e um índice extra em uma tabela que pode ser bastante usada, e fazer junções que seriam desnecessárias sem o uso de ‘chaves’ artificiais, geralmente o que se tem é perda de desempenho com as ‘chaves’ artificiais. Na prática, um sistema com chaves naturais é tão diferente de um com ‘chaves’ artificiais, que nunca se fazem testes realistas de comparação. A regra de evitar otimização precoce levaria a fazer um sistema só com as chaves naturais, e só acrescentar as artificiais quando se constantar algum problema real de capacidade ou de desempenho. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
