Pessoal, a discussao esta muito boa mas fugimos do tópico. On Jul 22, 2011 12:29 AM, "Leandro DUTRA" <[email protected]> wrote: > 2011/7/22 Vinicius Santos <[email protected]>: >> >> Ao inserir um novo registro na tabela "camisas" o Postgres precisa fazer >> a verificação de chave estrangeira, na tabela "cores". Por ser uma >> chave estrangeira VACHAR(30) ou CHAR(30), por exemplo, é mais caro, para >> o Postgres que se fossê uma chave do tipo inteira? > > Não. Talvez em casos muito, mas muito extremos mesmo, mas que eu > saiba isso nunca foi demonstrado. > > Isso dito, tem um artigo interessante do David Fetter nalgum lugar > recomendando evitar VARCHAR. O CHAR funciona muito bem. > > >> Será que a performance cairia, pelo fato de o tipo não ser INT ? > > Não. > > >> Uma junção entre chaves simples é muito mais rápido que uma entre chave >> composta ? > > Não. > > >> Ou nestes casos o que manda mesmo é sempre o bom-senso? "Vou utilizar >> uma chave artificial pois o tipo INT é mais rápido neste caso...". > > Não é bom senso, é ato reflexo. > > >> A vantagem de não fazer junções desnecessárias, e manter a modelagem >> "limpa", é tentadora. > > E conceitualmente correta. > > >> Caso estas questões de tipo sejam apenas "lendas urbanas" não vejo >> motivo algum para chaves artificiais. Estou errado ? > > Há muitas ferramentas que forçam o programador a escrever cada parte > de uma chave composta, por não terem operadores sobre um conjunto de > variáveis. Não tem nada a ver com modernidade, o Cobol já fazia isso > direito há quarenta anos, pelo menos. Isso leva os programadores a > procurarem criar uma chave simples. O problema é se criam chave > artificial mesmo quando as naturais serviriam perfeitamente, e pior > ainda quando esquecem de declarar as chaves naturais ao lado da > artificial. > > Outra situação que pode exigir uma chave artificial é quando (1) as > chaves naturais de uma relação (tabela) são todas compostas de muitos > atributos, e (2) exportadas para várias relações filhas maiores que a > pai, e (3) isso num volume muito, muito alto. Aí poderia, > eventualmente, acontecer da diferença de volume de dados armazenado e > em memória ser significativa. > > Deve haver alguma outra exceção à regra de evitar chaves artificiais > que não me lembro. O que não há é exceção à regra de sempre declarar > pelo menos uma chave natural, mesmo que se tenha sido obrigado a criar > uma artificial. > > > -- > Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 Google Talk: xmpp:[email protected] > +55 (11) 9406 7191 MSNIM:[email protected] > sip:[email protected] ICQ: AIM:GoIM?screenname=61287803 > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
