Bom, o que eu pensei é o seguinte…
Como são numeros eu gravaria cnpj como sendo int, e cpf tbm…mas tenho visto por ai o pessoal usar como String. Não seria errado?
To usando a Brazil Utils API pra validar o CPF, CNPJ…e pra validar os metodos recebe tudo string, dai to fazendo Integer.toString(int)
O que devo fazer?
Vou usar Hibernate e banco PostgreeSQL
Valeu!
vai ter que ser long, pois o valor maximo do integer nao suportaria o valor maximo de um cpf, ou seja o Integer.MAX_VALUE < 99999999999
++ editado ++
talvez utilizaram string para guardar o valor formatado, mas eh melhor guardar apenas os numeros pois a maioria dos validadores só recebem os numeros e a formatacao eh um detalhe da view, e acredito tb que o indice do banco seja mais rapido para numeros do que string.
ok entao tudo que é numero gravo no banco e na classe como sendo numero mesmo ne?
nao sei pq mta gente coloca como string, acho errado
tinha acabado de responder isso na edicao da msg anterior 
Oi,
Prefiro utilizar algum tipo alpha-numerico mesmo, no caso String, já me deparei com as seguintes situações:
- Nos campos de Inscrição Estadual foi necessário armazenar o literal “ISENTO”. Amanhã pode ser que um CPF tenha a necessidade de acrescentar algum caracter não numérico.
- Se o usuário digitar o CPF 001.234.334-23 alguns reclamam se o sistema depois apresentar 1.234.334-23, assim como também o contrário ele digitar com essa segunda opção e depois o sistema formatar para a primeira, ou seja é melhor deixar como ele digitou (não estou falando de guardar a mascara, mas dos dois ZEROS a esquerda).
1 curtida
Pense da seguinte maneira … Faz sentido você somar, subtrair, multiplicar ou dividir 2 CPF/CNPJ ? Ou então, pense de maneira prática. Pense que você tem que validar os dígitos verificadores do CPF. É muito mais simples percorrer cada dígito com getCharAt de String do que ficar fazendo divisões por 10. Ou seja, para decidir o tipo de dado você tem que pensar em quais operações serão realizadas sobre esse dado.
pra evitar isso eu sempre uso o DecimalFormat, mas ainda sobra o problema do cara colocar o digito verificador de um digito sem o zero a esquerda… ai ferrou mesmo
1 curtida
na verdade faz muito sentido pois esse numero eh validado, e sao operacoes bem chatinhas. mas como isso eh sempre feito por fora, nada que uma conversao pra long nao resolvesse. interessante seu ponto.
A escolha do tipo é fácil, isso vem das aulas de algoritmo, só devemos usar tipos numéricos se vamos fazer cálculos!
Tanto na lógica como no banco, fora isso textual mesmo. Mas como somos programadores java podemos criar um tipo CNPJ ou CPF e criar todo os métodos de conveniência nessa classe nova e criar um tipo personalizado do Hibernate para ele saber como persistir no banco!
Abraço espero ter ajudado.
Galera, é como o rmendes08 falou. Para decidir o tipo de dado a ser utilizado, precisamos saber que operações iremos fazer com ele. Por mais que CPF ou CNPJ sejam compostos por números, é praticamente improvável que a aplicação irá fazer alguma operação matemática com ele, então é String mesmo.
Att.
Concordo com o Joao.Gabriel e J@rge Luis
eu sempre vi o pessoal falando assim
e tambem sempre fiz assim