2011/6/29 Fabiano Machado Dias <fabi...@wolaksistemas.com.br>: > Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a > tão falada chave artificial para as PKs e fizemos as restrições devidas > nas chaves naturais (UKs), assim conseguimos resolver os problemas do > modelo físico e do lógico, claro que eles se misturam (não chegam ao > usuário mas ao programador sim), mas pra nós não é problema, aliás nunca > foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha > resposta a pergunta do colega!) > > Depois de trabalhar com tabelas em que a PK era composta por 16 campos e > tinha que juntar mais mais outras 20 tabelas, abolimos as PKs > compostas, isso me deu um ganho de performance bom e uma escrita rápida > também, a criação de índices também ficou fácil.
Esse é o plano B, melhor que as outras alternativas. O plano A, claro, seria usar chaves artificiais somente onde necessário, tipicamente mantendo as chaves compostas, onde não implicassem em perda de desempenho, como primárias. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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
