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. 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. > 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? >> 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. -- 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] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
