2010/1/7 Alexsander Rosa <[email protected]>: > Comentários no texto.
Tranqüilo, é o padrão. > 2010/1/7 Leandro DUTRA <[email protected]> >> >> Há vários motivos pelos quais CNPF ou CNPJ podem não ser chave natural >> — a questão que se coloca é, justamente, de qual entidade? >> > A entidade "cliente", por exemplo. Ou quem sabe, "fornecedor". Talvez exista > uma entidade "pessoa" que contém apenas os dados básicos (nome, cpf/cnpj, > etc) e as demais, como "cliente", "fornecedor", "funcionário", etc sejam > especializações. Exato — ao menos, conceitualmente, normalizando. A questão é se vale a pena implementar; mas essa só pode ser respondida para situações específicas. Genericamente, é preciso analisar as chaves (entre outras coisas) para descobrir até onde se deve normalizar, para só então decidir o que dá para implementar, entre tudo que se descobriu. > De qualquer forma, não é prático usar, digamos, o nome > completo (+ nome da mãe para o caso dos homônimos): imagine um setor da > empresa conversando com outro, por telefone, sobre um cliente específico. Usar como? Usar como chave primária, ou como única chave, provavelmente. Já declarar como chave natural, ainda que não a primária, é necessário para evitar duplicações. Especificamente nesse exemplo, provavelmente precise-se de uma chave composta, visto que mesmo o conjunto de nome e filiação não costuma ser chave. > Tradicionalmente as empresas criam um "código de cliente" para cada cliente > mas permitem que eles cheguem no balcão munidos apenas com o CPF e localizem > seu registro. A chave natural não deixa de existir, apenas não é primária. Aí está certo. > Indo por este caminho acabaríamos criando entidades para escolas (cuja chave > primária pode ser o código INEP, como foi dito aqui), agências dos correios > (cada agência tem seu número), agências de alguns bancos públicos (nº do > banco + nº da agência), sedes do SESC (deve haver algum código que eles > usam) e assim por diante. Exato. O SQL não ajuda muito, mas pode ser necessário. Não necessariamente com códigos particulares, embora eles sejam atraente. Poderia ser endereço, por exemplo. >> Sendo mais preciso, pode ser necessária uma chave artificial; mas não >> tentar uma chave natural, mesmo que não seja declarada como a >> primária, seria convidar problemas pela porta da frente. >> > Mas este é o processo: tentar em primeiro lugar uma chave natural como chave > primária. Exato! Conversando com boa vontade, a gente se entende… >> > Sou totalmente a favor de chaves naturais, uso sempre que possível, mas >> > há casos em que simplesmente não dá. >> >> Não dá para usar como chave primária, não estou preocupado. >> > Eu me refiro a "usar como chave primária". Tudo certo. > "Extremismo na defesa da liberdade não é defeito. > Moderação na busca por justiça não é virtude." > -- Barry Goldwater Hm, acho que não concordo… OT! :-) -- 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] Sent from Sao Paulo, SP, Brésil _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
