Cpf Duplicado

[Popin 0]

Ola... preciso fazer uma verificação de cpf duplicado no meu sistema, e não sei como fazer. Ja vi varias formas de se fazer na internet, mas não

sei qual a melhor forma.

 

Alguém pode me ajudar???

Desde ja obrigado.

[kadu_17 3]

como assim cpf duplicado?

 

quando você esta construindo o banco de dados você ja define se o campos vai ser campo único ou n.

 

cpf eh campo único no cadastro você n pode deixar ele ser = a um existente

 

explica melhor ai oq você ta querendo pra poder te uma ideia...

 

flwww

[Popin 0]

como assim cpf duplicado?

 

quando você esta construindo o banco de dados você ja define se o campos vai ser campo único ou n.

 

cpf eh campo único no cadastro você n pode deixar ele ser = a um existente

 

explica melhor ai oq você ta querendo pra poder te uma ideia...

 

flwww

 

E isso mesmo que você flw, mas agora vou colocar no banco ele como unique, dai quando eu for inserir um valor duplicado ele vai dar erro de ecessão, certo?

[Mário Monteiro 179]

certamente dará erro mas é bom tratar antes par ao usuário não ser penalizado

[WanderAlex 0]

 

como assim cpf duplicado?

 

quando você esta construindo o banco de dados você ja define se o campos vai ser campo único ou n.

 

cpf eh campo único no cadastro você n pode deixar ele ser = a um existente

 

explica melhor ai oq você ta querendo pra poder te uma ideia...

 

flwww

 

E isso mesmo que você flw, mas agora vou colocar no banco ele como unique, dai quando eu for inserir um valor duplicado ele vai dar erro de ecessão, certo?

 

 

Boa noite.

 

Crie um script para identificar na sua base de dados quais registros estão duplicados e exclua-os, depois crie a unique. Como trata-se de uma unique por segurança realizar os devidos tratamentos.

 

Espero ter ajudado.

[Popin 0]

Ja esta resolvido.

[Prog 183]

quando você esta construindo o banco de dados você ja define se o campos vai ser campo único ou n.

 

cpf eh campo único no cadastro você n pode deixar ele ser = a um existente

 

Esta afirmação não é totalmente correta, dependendo do tipo de sistema a duplicação de CPF é aceitável. CPF não é necessariamente um "campo único no cadastro".

[kadu_17 3]

pq não?

 

cpf em teoria cada pessoa/usuário cadastrado tem o seu ...

 

você pode não utilizar esse campo como unico , mas certeza q eh uma chave candidata =)

[Prog 183]

É fato que o CPF é único por pessoa, mas nem toda pessoa tem CPF, embora este seja um bom item identificador, mas, como eu disse, dependendo das regras de negócio do sistema, este não pode ser tratado como uma informação que não possa se repetir.

 

Exemplo: Sistema Acadêmico

Você tem um sistema o qual você pretende comercializa-lo para escolas de primeiro grau, segundo grau e cursos profissionalizantes. O CPF é obrigatório apenas para pessoas acima de 18 anos, embora nenhuma lei determine que um cidadão não possa fazer seu cadastro com idade menor. Nas regras de negócio do sistema fica determinado que o cadastro do CPF é obrigatório (poderia não ser, mas para evitar inconsistências, certamente você, ou quase que a totalidade de nós, coloque este campo como obrigatório). O que fazer para que um cidadão possa se matricular num curso se ele não possui CPF? Perde o aluno? Cadastra o CPF do responsável? E se algum irmão, ou mesmo o próprio responsável também for ou já estiver matriculado? Parametriza o campo como "não obrigatório"? Mas, se o mesmo não é obrigatório, campos em branco caracterizam repetição. Retira a obrigatoriedade do CPF?

 

Se você começar a analisar friamente, em quase qualquer sistema pode acontecer uma exceção que pode implicar na repetição do cadastro de CPF. Pensar em normalizar o modelo pode até encontrar alguma solução, mas normalizar demais também não é uma boa solução, pode prejudicar a performance.

 

cpf em teoria cada pessoa/usuário cadastrado tem o seu ...

 

Chave candidata? As vezes! Chave primária? Nunca! Pelo menos, não somente o CPF.

[Manoel - 0]

É fato que o CPF é único por pessoa, mas nem toda pessoa tem CPF, embora este seja um bom item identificador, mas, como eu disse, dependendo das regras de negócio do sistema, este não pode ser tratado como uma informação que não possa se repetir.

 

Exemplo: Sistema Acadêmico

Você tem um sistema o qual você pretende comercializa-lo para escolas de primeiro grau, segundo grau e cursos profissionalizantes. O CPF é obrigatório apenas para pessoas acima de 18 anos, embora nenhuma lei determine que um cidadão não possa fazer seu cadastro com idade menor. Nas regras de negócio do sistema fica determinado que o cadastro do CPF é obrigatório (poderia não ser, mas para evitar inconsistências, certamente você, ou quase que a totalidade de nós, coloque este campo como obrigatório). O que fazer para que um cidadão possa se matricular num curso se ele não possui CPF? Perde o aluno? Cadastra o CPF do responsável? E se algum irmão, ou mesmo o próprio responsável também for ou já estiver matriculado? Parametriza o campo como "não obrigatório"? Mas, se o mesmo não é obrigatório, campos em branco caracterizam repetição. Retira a obrigatoriedade do CPF?

 

Se você começar a analisar friamente, em quase qualquer sistema pode acontecer uma exceção que pode implicar na repetição do cadastro de CPF. Pensar em normalizar o modelo pode até encontrar alguma solução, mas normalizar demais também não é uma boa solução, pode prejudicar a performance.

 

 

cpf em teoria cada pessoa/usuário cadastrado tem o seu ...

 

Chave candidata? As vezes! Chave primária? Nunca! Pelo menos, não somente o CPF.

 

Afa é mesmo!?

http://forum.imasters.com.br/public/style_emoticons/default/ermm.gif

Normalizar demais também não é uma boa solução porque prejudica a performance?

Na verdade nunca ouvir falar nisso, so se quem fez a normalização foi um animal né!

[Prog 183]

Afa é mesmo!?

http://forum.imasters.com.br/public/style_emoticons/default/ermm.gif

Normalizar demais também não é uma boa solução porque prejudica a performance?

Na verdade nunca ouvir falar nisso, so se quem fez a normalização foi um animal né!

 

Quanto mais JOINs, menor é a performance de uma QUERY. Quanto mais normalizado, mais JOINs, logo... menor a performance.

 

Esta condição deve ser levada em consideração, mas nem por isso alguém vai jogar tudo numa única tabela. Tanto a normalização quanto a desnormalização devem ser considerados num projeto, seguindo critérios para cada regra de negócio, se este for o caso, para obter o melhor resultado.