2009/12/30 Andre Fernandes <[email protected]>: > > Desculpa-me entrar nesta discussão, contudo neste exemplo mencionado há um > possível erro de modelagem, o problema não é a chave artificial > explicitamente.
Como eu disse, é um exemplo simplérrimo, somente para demonstrar o problema, a saber que chave artificial não garante unicidade. > Chaves artificiais não são um mal por si só Na forma como implementadas hoje, são. Originalmente, eram uma idéia interessante, mas creio que não foram implementadas em nenhum sistema. Infelizmente, são um mal necessário em algumas situações. Mas somente complementando as naturais, nunca substituindo. > Concordo que chaves artificiais podem ser problema quando o modelo está errado Não apenas, podem ser problemas físicos também. > nem sempre chaves naturais são adequadas ou mesmo possuem bom desempenho Sempre são adequadas e sempre possuem bom desempenho — a não ser em situações bem específicas, como já descritas. > (imagine uma chave composta onde todos os campos são strings, pode ser muito > ruim para um bom desempenho de consultas). Mito. > Além do mais, um id interno para o usuário, para a empresa, etc., pode ser > facilmente entendido, não é um monstro que complica tudo. Mas obscurece quais as chaves verdadeiras. Geralmente, dificulta o entendimento. > (lembre-se que nem as regras de normalização sempre devem ser seguidas, há > momentos em que precisamos ferir uma delas para que o desempenho não seja > ínfimo). Mas isso por limitações do SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:[email protected] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[email protected] Sent from Sao Paulo, SP, Brazil _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
