Olá, não recebi as mensagens anteriores, parece que havia sido "removido" da
lista ("bouncing(ssssss)"?), então talvez repita algo que já foi dito... (peço
desculpas antecipadas)
Em seg 11 jul 2011, às 09:54:35, Alexsander Rosa escreveu:
> No meu ERP uso um parâmetro "digitos_empresa" (geralmente 4) para montar a
> chave. Exemplo: o 1º cliente cadastrado na filial 7 fica com código 10007
> que é mostrado como "1/7" no sistema. O cliente nº 357 da filial 24 fica
> com código 3570024 e assim por diante. Como já foi discutido aqui antes, a
> chave artificial vira natural quando "sobe" até o mundo real -- o número
> do cliente aparece nos orçamentos, pedidos e na NF-e; também é comum o
> cliente telefonar e dizer "sou o 2467/2" por exemplo.
>
> Na minha opinião, a entidade "cliente" (ou "pessoa" como eu prefiro
> modelar) fica melhor modelada com um "código" sequencial. Chaves naturais
> existem mas não são suficientes. Por exemplo, nem CPF nem CNPJ servem como
> PK: o CPF é reusado alguns anos depois do falecimento do titular e muitos
> órgãos ṕublicos compartilham o mesmo CNPJ -- por exemplo, TODAS as escolas
> estaduais do RS usam o CNPJ da Secretaria da Educação do estado.
Esse assunto é tão recorrente quanto importante, inclusive a informação sobre
essa "anomalia" das escolas do RS já foi citada há uns anos atrás.
E nunca se chega a uma conclusão, creio que é pela tentativa (e necessidade)
de modelar algo confuso (ou incorreto), pois não há uma *chave primaria* real
na sociedade brasileira, como já disse em outra oportunidade, se usarmos o cpf
como chave primaria, estariamos modelando não uma pessoa (ou um cliente), mas
sim:
Uma pessoa com registro na Receita Federal do Brasil.
Já foi sugerido o uso de um chave artificial, que não apareça para
clientes/usuários, essa parece boa, mas o problema é *cultural*, as pessoas
estão acostumadas com um "código", e se assustam quando não o têm.
Dito isso, já pensei em algo como hash/md5 ou coisa parecida na união de
atributos "chaves" (nome, data nascimento ...), mas também não consegui algo
satisfatório.
Será esse é nosso "Santo Graal"?
>
> Em 9 de julho de 2011 06:41, Pablo Sánchez <[email protected]> escreveu:
> > Pelo que estou vendo vc quer trabalhar com uma aplicação "off-line" que
> > quando entre on-line faça o upload das informações trabalhadas
> > localmente, correto?
> >
> > O campo serial nada mais é que uma constraint ON INSERT que busca o
> > nextval da sequence a ele associado. Você poderia simplesmente criar uma
> > constraint que criasse um valor para vc, não necessariamente aleatório,
> > poderia ser um identificador composto por id do usuário que criou, mais
> > um identificador único de instalação (sei lá, inventa), mais um sequence
> > local só para isso. Aí, quando criasse ficaria algo como
> >
> > 10/INST10002-1
> >
> > Ou qualquer coisa assim. O lance é que se resolve simplesmente com uma
> > boa pensada em como compor sua chave, e criando a constraint.
Se formarmos rotinas/algorítimos como eu dissse acima, seria uma boa usar usar
essas idéias para concretizar "a coisa".
[]'s
--
Johnny Taylor Faria Chaves - LUN 157066
www.brdados.com.br - jfchaves <at> brdados.com.br
Eu não posso mais, se você pode, doe sangue!!!
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
