Em Sex 05 Mar 2010, às 21:05:37, Leandro DUTRA escreveu: > 2010/3/5 Flávio Alves Granato <[email protected]>: > > uma "boa" implementação de chaves compostas pode ser um objeto, por > > exemplo, chamado idAlgumaCoisa > > contendo os atributos referentes à chave natural? > > Por aí, é como se faz em COBOL. > > > o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas > > gigantes? > > Qual custo? Afinal, nenhuma chave é alterada constantemente.
Concordo. > > E esse custo amiúde é compensado por evitar junções devido ao uso de > chaves artificiais, pela economia do índice associado, pelo > ‘emagrecimento’ das tabelas… > > > Concordamos que cpf e cnpj são boas chaves naturais candidatas > > Não necessariamente. por isso eu disse boa. > > > mas e para o caso de uma tabela em que só tenha um atributo, como existe > > muito, uma tabela cargo relacionando com funcionário e nesta tabela > > cargo só se tem o nome do cargo. Minha pergunta é, seria melhor forçar o > > dono do sistema fazer uma codificação para cada cargo, tipo, A-1 : > > Gerente ou A-2 : Arquiteto > > Não entendi. > > Qual o problema do nome do cargo ser chave? Para quê esse código? Mas ai eu ficaria duplicando informação. E para isso existiriam as chaves artificiais, não? > > >> O que não se pode jamais fazer é definir apenas a chave artificial, e > >> não a(s) natural(is). > > > > Com este comentário, acabo achando que a criação de códigos para uma > > chave natural para uma determinada tabela como exemplo a tabela cargo > > acima é válido. > > Não entendi mesmo. o mesmo acima. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
