Executando verificação de segurança...
7

O problema de guardar como número é que o zero à esquerda pode acabar sendo ignorado, já que para um número, 02, 000002 e 2 são basicamente a mesma coisa: ambos representam o mesmo valor numérico, a mesma grandeza/quantidade (muda apenas a formatação). E aí temos erros grotescos - e na minha opinião imperdoáveis - como o que ocorreu com a Caixa certa vez (o sistema removia o zero à esquerda e dava erro porque o CPF estava inválido).

Pra mim, é uma economia que não vale a pena. Ainda mais se a empresa for grande (como um banco, por exemplo), pois a suposta economia de memória não justifica os eventuais erros que podem acontecer. Até porque os bancos devem guardar uma quantidade tão absurda de informações que os CPF's e CNPJ's devem ocupar uma porcentagem bem pequena do todo. E mesmo se a empresa for pequena, ainda acho que não justifica. É o típico caso de micro-otimização desnecessária e que acaba causando outros problemas.

Informações como o CPF, CNPJ, RG, telefone, CEP e similares não são números, pelo menos não no sentido de representar uma quantidade e/ou precisar fazer cálculos com eles ("vamos somar seu CPF com o CEP da sua casa, e calcular a média dos seus telefones"). Eles são identificadores/códigos que por acaso usam dígitos - aliás, alguns podem ter letras, como RG (e agora o CNPJ), por exemplo. E o zero à esquerda faz toda a diferença, ao contrário do que acontece com números.

Então o correto é guardar como texto mesmo. Leitura adicional:

Carregando publicação patrocinada...
Conteúdo excluído
4

Só de curiosidade, como vc trataria a questão do zero à esquerda? Por exemplo, se vc guarda o valor 02312142007 como número (por exemplo, se for no banco de dados, em uma coluna do tipo NUMBER), o que será gravado será o valor numérico 2312142007 (o zero "se perde", já que do ponto de vista do valor numérico, ele é irrelevante).

As "soluções" (gambiarras) que eu já vi envolvem converter o número para string e ver o tamanho (se menor que 11, adiciona o zero), etc. Coisas que não seriam necessárias se já estivesse guardado como VARCHAR.

E provavelmente foi esse o motivo do já mencionado erro no sistema da Caixa. Se o zero à esquerda faz diferença, se o dado é uma informação que serve mais - ou apenas - como identificador, se ele não representa uma quantidade e/ou não faz sentido realizar cálculos com ele, são fortes indícios de que não deveria ser guardado como número, e sim como texto. E documentos como o CPF e CNPJ preenchem todos esses requisitos, então são fortíssimos candidatos a serem tratados como texto.

Vc pode até achar que não tem maneira correta, mas com certeza existem soluções com menos desvantagens e menor propensão a erros. E tratar CPF/CNPJ (e telefone, RG, CEP, matrícula/códigos diversos - e até mesmo o número do endereço, pois há casos em que a casa é "s/n", por exemplo) como texto possui mais vantagens do que desvantagens.

4

As "soluções" (gambiarras) que eu já vi envolvem converter o número para string e ver o tamanho (se menor que 11, adiciona o zero), etc.

Estou consumindo uma API do Santander agora e em alguns campos de documento (CPF/CNPJ) ele retorna sem zero, outros com zero. Como não sei o comportamento exato (a documentação não menciona isso), terei que fazer um baita tratamento para conseguir identificar corretamente e preencher de acordo (visto que o CNPJ do Banco do Brasil, por exemplo, é 00.000.000/0001-91, então talvez o Santander me retornasse pela API 191).

O documento vem acompanhado de uma outra propriedade que indica se é CPF ou CNPJ, e eu até ia usar essa propriedade, mas vi um retorno com o valor 2 (como string), então eu precisarei tratar tudo isso.

Fica minha recomendação aos desenvolvedores: facilitem a vida de vocês e, principalmente, dos outros.

PS: RG, ao menos de São Paulo, pode ter letra (X), e tem lugar que não aceita letra e é necessário inserir um número no lugar (nesse caso, 0). Mais um exemplo de que isso não é uma boa escolha.