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 <phack...@gmail.com> 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
