Em 22/7/2011 00:29, Leandro DUTRA escreveu: > 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.
Você tem algum material, livro, documentação oficial onde isso seja documentado com mais detalhes? No caso estou me referindo as 3 repostas, lembro de já ter procurado na documentação e não ter encontrado. Não estou duvidando, apenas gostaria de ver algum artigo ou explicação mais consistente, já vi outras opiniões parecidas aqui na lista, mas nunca ninguém citou um material onde isso estivesse documentado. > > >> 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. > > Abraço, Fabiano Machado Dias _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
