none
Ajuda com código cliente RRS feed

  • Pergunta

  • Tudo bom amigos,

    Estou com uma dúvida:

    Temos um sistema que estamos em fase de análise onde será usado por 3 empresas diferentes(do mesmo grupo), estamos na dúvida de como o código do cliente ser o mesmo código em todas as empresas, ou seja, vamos montar uma replicação porém não sabemos como criar esse código, qual seria a dicas de vcs para criar esse código, lembrando que temos uma tabela de cadastro de empresas.

     

    Devemos usar o CNPJ ou CPF com chave primária?

    Qual a dica de vcs?

     

    Muito obrigado

     

     

     

     

    terça-feira, 28 de julho de 2009 16:54

Respostas

  • Boa Noite,

    Eu normalmente não gosto de chaves naturais como o CPF e o CNPJ. Na minha opinião elas deixam o modelo refém de regras de negócio que podem mudar. O que acontece por exemplo se uma coluna CNPJ passar a ser opcional ? Ou ainda se a coluna CPF passar a aceitar duplicadas (no caso do cônjuge poder utilizar o CPF), ou ainda se você necessitar de guardar versões de um mesmo cliente ? São algumas situações em que as chaves naturais "quebram" o modelo e realizar os ajustes é bem mais complicado.

    Em contrapartida... Na sua situação, como é necessário garantir unicidade entre todas as empresas, utilizar-se de chaves naturais pode ser uma boa idéia. O uso de chaves artificiais até funcionaria (talvez com ranges de Identities ou algo assim), mas nesse caso o uso de chaves naturais (visto os riscos associados) pode ser uma implementação mais fácil.

    [ ]s,
     
    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY
    Parte 01 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry
    Parte 02 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry


    Classifique as respostas. O seu feedback é imprescindível
    quarta-feira, 5 de agosto de 2009 00:35
  • Maia,

           Eu acho que o meio termo é essencial para resolver esse problema. O que eu penso é que neste caso específico, a chave natural será melhor porque evitará grandes dores de cabeça...
           Uma outra coisa que eu estava pensando é o seguinte: O cenário informa que eles querem ter o mesmo CPF/CNPJ em quaisquer das empresas. Ok. Usando Loja+Codigo e o CPF/CNPJ como um campo adicional (obrigatório  e único), imagine se duas lojas ao mesmo tempo cadastram o mesmo CPF. Loja 1, Código 123, CPF 111.111.111-11. Loja 2, Código 324, CPF 111.111.111-11, qual o cadastro válido? Se optar por quaisquer dos cadastros, ainda assim terá que ser feito um rastreamento do outro código (agora inválido) nas tabelas para apontar para o novo código. Se for pelo CPF/CNPJ, ainda assim haverá o conflito, porém, não importa qual dos dois será o válido, ambos apontam para o mesmo cadastro, neste caso 111.111.111-11
    MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008
    quarta-feira, 5 de agosto de 2009 00:54
    Moderador

Todas as Respostas

  • Zuricbr,

    Eu não utilizari o CNPJ ou CPF como chave primária, mas sim um código que representa cada empresa, como por exemplo:


    Código 01 - Empresa A
    Código 02 - Empresa B
    Código 03 - Empresa C

    Trabalhando com um campo do tipo integer ou smallint para armazenar o código da empresa e este mesmo campo poderia ser a chave primária.

    Em outras tabelas fazendo o relacionamento como chave estrangeira.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Sugerido como Resposta mkn.Net quarta-feira, 29 de julho de 2009 13:47
    terça-feira, 28 de julho de 2009 16:58
  • Junior,

    Seria fazer uma junção de um código + código da empresa = código do cliente?

    Uma chave primária composta: Codigo e código da empresa?

    Nossa idéia seria fazer um replicação que o cadastro de cliente seja o mesmo em todas as empresas, sendo essa replicação em um prazo curto, evitando que o cliente tenha dois cadastros nas empresas.

    Você deixaria ele ter mais de um cadastro nas empresas separado por empresa, fazeria de outra forma?

     

    Agradeço pela ajuda

     

    terça-feira, 28 de julho de 2009 17:16
  • Olá Zuricbr.

    Você pode usar o código como chave primária e colocar uma constraint para que o cnpj / cpf não se repita.

    []'s
    terça-feira, 28 de julho de 2009 17:26
  • Zuricbr,

         Diferentemente dos colegas, eu recomendaria que a sua chave primária fosse o CPF ou CNPJ. Acho importante no momento da modelagem dos seus dados, você levar em consideração a chave candidata. O conceito de chave candidata é um (ou mais) campos que podem vir a se tornar chave primária, e que identificam exclusivamente um registro.

         No seu caso, eu acho que a melhor alternativa, a menos que algum cliente não possua CPF ou CNPJ, você não deve usar a chave primária como um campo identity (chamado de chave artificial)....

         Veja o conceito sobre chave candidata na wikipedia (http://pt.wikipedia.org/wiki/Modelo_relacional)


    MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008
    terça-feira, 28 de julho de 2009 18:58
    Moderador
  • Pessoal.
     
    Mais queriamos que o código fosse único ou seja, independente de que empresa o cliente fosse realizar uma compra o seu codigo seria o mesmo.

    Agradeço a ajuda

    quarta-feira, 29 de julho de 2009 12:49
  • Zuricbr,

          O uso do CPF ou CNPJ evitaria que você tivesse que ter uma chave composta (Loja + Código) além do que, você ainda teria que controlar o range de códigos para cada loja. Além disso, você ainda teria que lidar com os conflitos que certamente aconteceriam. Outro ponto negativo, é que o cliente que foi adicionado na loja 1, por exemplo Loja 1, Codigo 123, e ele fosse comprar na loja 2, a loja 2 teria que de alguma forma consultar o código (1+123) para poder encontrar o seu cliente.... Ok, você pode estar dizendo: "Não, eu vou fazer as buscas por CPF ou CNPJ!", neste caso, porque não fazer a replicação baseada no CPF ou CNPJ??? A a chave primária, sendo Loja+Código e você sempre fazendo buscas por CPF ou CNPJ você terá perda de performance pois seu índice (não-pk) terá que efetuar a busca, localizar onde os dados estão na chave primária e ler os seus na localização da tabela (no índice clusterizado - Leaf node)


    MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008
    sexta-feira, 31 de julho de 2009 01:23
    Moderador
  • Zuricbr,

    Você conseguiu solucionar o seu problema?
    Caso afirmativo poste a solução para que outras pessoas se beneficiem.

    Att,
    Fernanda


    “Caso esta resposta tenha ajudado a solucionar sua dúvida, favor clicar em “Marcar como Resposta” para beneficiar outros membros da comunidade que estejam lendo este thread”.
    terça-feira, 4 de agosto de 2009 14:09
  • Boa Noite,

    Eu normalmente não gosto de chaves naturais como o CPF e o CNPJ. Na minha opinião elas deixam o modelo refém de regras de negócio que podem mudar. O que acontece por exemplo se uma coluna CNPJ passar a ser opcional ? Ou ainda se a coluna CPF passar a aceitar duplicadas (no caso do cônjuge poder utilizar o CPF), ou ainda se você necessitar de guardar versões de um mesmo cliente ? São algumas situações em que as chaves naturais "quebram" o modelo e realizar os ajustes é bem mais complicado.

    Em contrapartida... Na sua situação, como é necessário garantir unicidade entre todas as empresas, utilizar-se de chaves naturais pode ser uma boa idéia. O uso de chaves artificiais até funcionaria (talvez com ranges de Identities ou algo assim), mas nesse caso o uso de chaves naturais (visto os riscos associados) pode ser uma implementação mais fácil.

    [ ]s,
     
    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY
    Parte 01 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry
    Parte 02 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry


    Classifique as respostas. O seu feedback é imprescindível
    quarta-feira, 5 de agosto de 2009 00:35
  • Maia,

           Eu acho que o meio termo é essencial para resolver esse problema. O que eu penso é que neste caso específico, a chave natural será melhor porque evitará grandes dores de cabeça...
           Uma outra coisa que eu estava pensando é o seguinte: O cenário informa que eles querem ter o mesmo CPF/CNPJ em quaisquer das empresas. Ok. Usando Loja+Codigo e o CPF/CNPJ como um campo adicional (obrigatório  e único), imagine se duas lojas ao mesmo tempo cadastram o mesmo CPF. Loja 1, Código 123, CPF 111.111.111-11. Loja 2, Código 324, CPF 111.111.111-11, qual o cadastro válido? Se optar por quaisquer dos cadastros, ainda assim terá que ser feito um rastreamento do outro código (agora inválido) nas tabelas para apontar para o novo código. Se for pelo CPF/CNPJ, ainda assim haverá o conflito, porém, não importa qual dos dois será o válido, ambos apontam para o mesmo cadastro, neste caso 111.111.111-11
    MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008
    quarta-feira, 5 de agosto de 2009 00:54
    Moderador
  • Olá Roberto,

    Sim eu concordo. Nesse caso específico, o CNPJ pode sim ser um boa escolha pelos motivos que você falou.

    [ ]s,
     
    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY
    Parte 01 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry
    Parte 02 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry


    Classifique as respostas. O seu feedback é imprescindível
    quarta-feira, 5 de agosto de 2009 01:49