Em Qui, 2007-06-21 às 13:55 -0300, Wallace Reis escreveu:
> > Interessante, um fala que é impróprio usar as chamadas surrogates key e o
> > outro fala que é má pratica usar campos que realmente são candidatos a chave
> > primária.
> 
> Realmente, eles são *candidatos* a chave primária, mas acredito ser má
> pratica porque: i) é uma chave que você não tem controle sobre ela,
> então no dia que o governo resolver mudar a lógica do CPF ou do RG
> isso vai te trazer grandes dores de cabeça

        Por que vai?

        Em último caso, ON UPDATE CASCADE e fim de papo.

        Eu não vejo problema algum.  Uma mudança nas chaves naturais é uma
mudança drástica intrinsecamente, não vai ser uma chave artificial que
vai ajudar.


> ii) é uma chave que contém
> informações (ex. no CPF dos baianos o último dígito antes do "-" é 5),
> o que não é objetivo, descrição dos dados, de uma chave primária

        E daí?  O CPF é informado externamente, não tem problema algum.  O
problema é se você mistura várias informações em atributos que você
mesmo gera, independente de serem chaves ou não.

        Em último caso, CHECK CONSTRAINT.


> iii)
> são chaves naturais no Brasil, logo restringe seu banco de dados a
> brasileiros.

        Esse é um problema de modelagem.  Você criou uma entidade ‘brasileiro’,
não uma entidade ’pessoa’.


> Enfim por estas e outras razões (que não me recordo no momento) disse
> ser má prática, não que é proibido.

        Não, é ótima prática.


> Não. Toda tabela *deve* ter uma chave primária.

        Toda tabela *tem* de ter ao menos uma chave natural.  A questão de ser
primária é bem arbitrária.  Chaves artificiais podem até complementar as
naturais, mas nunca substituir.


-- 
Leandro Guimarães Faria Corcete DUTRA  <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas  SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat     +55 (11) 3040 7300 r151


- - - - -

Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou 
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber 
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas 
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta 
mensagem por engano, por favor avise imediatamente o remetente, respondendo o 
e-mail e em seguida apague-o. Agradecemos sua cooperacao.

Privacy Policy: This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose or take any action based on this 
message or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a