>>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.

Nada a ver com a discussão em questão.. acredito que  CPF e CNPJ não podem
ser reusados.. não do sentido de, um cara tem um CPF, morreu.. e depois de
alguns anos alguém aparecer com o mesmo numero... pode ser que ser usado por
mais de um estabelecimento, como o amigo disse, mas o numero ser
reaproveitado.. será?

Se for verdade, eis um meio de muitos fraudar o estado.. hehee

T.·.F.·.A.·.     S+F

*Fellipe Henrique P. Soares*

Analista e Desenvolvedor de Softwares for Win32
Linux Administrator




Em 11 de julho de 2011 09:54, Alexsander Rosa
<[email protected]>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.
>
> 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.
>>
>>
>>
>
> --
> Atenciosamente,
> Alexsander da Rosa
> http://rednaxel.com
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a