Pois é, vejo que, em parte, eu meio que entendia errado essa "critica" às chaves artificiais. Hoje mesmo quando enviei a primeira pergunta eu me referia ao uso de chaves naturais compostas em relacionamentos, ou seja, como chaves primárias. Eu me refira justamente a uma modelagem sem chaves artificiais, onde os campos que compunham as chaves primárias são replicados nas outras tabelas. Esse tipo de modelagem acredito ser complicado em requisitos de hardware limitados principalmente por alguma restrição de armazenamento.
Em 28 de abril de 2015 20:12, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 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 >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
