Banco de Dados – Dilema : Tipo de Dados para campos de CPF/CNPJ e Data.

Venho por decorrer observando que umas das duvidas em relação a sistemas que necessitam a persistência de dados como CPF,CNPJ e Datas, vem sendo uma questão no caso de uso de cada um, e pela necessidade apresentada pelo escopo do projeto, porem existem casos em que a modelagem de dados de um software que foi apresentado pode ser implicativa em relação ao funcionamento adequando do sistema, talvez por equivoco ou por não conhecimento. Quando vem a seguinte questão , que vi em alguns fóruns : “Que tipo de dados usar quando o campo necessita armazenar um CPF , CNPJ ou Data ?”

Bom , espero que a resposta seja breve e explicativa, e também espero que esta pergunta não seja feita quando o software já esta em fase final ! , porque? Um agravamento no funcionamento de um sistema ocorre quando certas medidas que eram para ser tomadas no inicio como na diagramação, na modelagem, no levantamento de requisitos, nas estruturas UML, são tomadas no fechamento do projeto, isto faz com desestabilize completamente a lógica usada na sua camada de negociação com o banco.

Desmistificando Pensamentos …

CNPJ e CPF são campos que tem tamanhos fixos. Um CPF sempre irá ter no máximo 11 caracteres (*Isso sem contar a mascara … Acabei lembrando … Para que salvar uma mascara no banco ??? … Para nada … Neste caso a todo instante, teríamos que colocar em nossas cláusulas uma conversão para VARCHAR e tratar os zeros iniciais. Essa formatação acabaria denegrindo os ganhos nas pesquisas (além de ser um passo bem chato … então continuando…)… Um CNPJ sempre irá ter 14 caracteres, por isso o mais adequado seria utilizar o tipo de dados char.

Não é bom utilizar nenhum dos tipos de dados numericos nesses casos, porque você pode ter problemas com os registros que comecam com 0 (Zero). Por exemplo: CPF 01234567891, na tabela do  banco de dados ele irá salvar sem o 0 (Zero) inicial. Mentira ?? … Testem este CPF por exemplo : 00000014141 *(Este CPF é matemáticamente correto , portanto é dado como CPF válido).

Além disso dependendo do tamanho do campo pode acontecer até de um valor ser maior do que o limite do tipo de dados numérico… Como ??? Qual é o tamanho de um inteiro ? -2.147.483.648 a 2.147.483.647 (-231 a 231 − 1). Portanto não funciona. E um Long ?? Um long é um inteiro de 64 Bits … Bom , este caso funciona , porém o retorno não será dos mais agradáveis… Portanto … Tipo de dados (Char).

Quanto a data, o datetime é o mais utilizado, mas na grande maioria dos casos você pode utilizar o smalldatetime, ou timestamp. a diferença entre os está no espaço que ele irá utilizar ou o intervalo de valores que cada um pode armazenar.

Espero que ajude.

9 opiniões sobre “Banco de Dados – Dilema : Tipo de Dados para campos de CPF/CNPJ e Data.”

  1. Quanto a armazenar dados com “máscaras”, acho que isto é inviável citando somente dois pontos: performace dos índices e espaço de armazenamento (pensando em grande escala).
    Falando sobre o tipo adequado para armazenamento de valores como CPF e CNPJ, voto no VARCHAR, a não ser que esteje disposto a formatar o mesmo até mesmo na recuperação do valor.
    Quando o assunto é data, devemos ter cuidado para não cair no penssamento ” não sei o que usar, então vou usar VARCHAR “, pense assim e depois me fale quando precisar utilizar um BETWEEN…

    Falow Estevão, é isso ai mesmo !

  2. Parabéns pela descrição sobre os tipos relacionados.

    Porém , prefiro utilizar algum tipo alpha-numerico mesmo, no caso String, já me deparei com as seguintes situações:

    1. 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.
    2. 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).

  3. Na minha visão, utilizar CHAR para armazenar CPF e CNPJ é a melhor escolha, pois você já sabe o tamanho dos dados, diminiu processamento do banco, pois VARCHAR exige mais processamento e no caso da formatação é só na visualização, nada que uma boa classe não resolva. Para o caso da data, prefiro utilizar o Timestamp, pois consigo gerenciar meus relatórios inclusive filtrando por hora.

    Abraços Estevão !!!

  4. Uma questão de análise e ambiente. temos caso em que o tratamento será no banco ou na aplicação, esta questão acho que depende muito do padrão em que a empresa está habituada e quem são seus clientes em potencial (Estação potencial, servidor potencial, fluxo de dados na rede, etc). a respeito da validação (000…), pode depender da politica que se vai usar tbm. acho que não existe uma melhor forma, e sim um melhor conjunto de soluções para o cliente(pois é nele que temos que pensar.)

    abraços. Estevão.

  5. Indio NETi :
    Na minha visão, utilizar CHAR para armazenar CPF e CNPJ é a melhor escolha, pois você já sabe o tamanho dos dados, diminiu processamento do banco, pois VARCHAR exige mais processamento e no caso da formatação é só na visualização, nada que uma boa classe não resolva. Para o caso da data, prefiro utilizar o Timestamp, pois consigo gerenciar meus relatórios inclusive filtrando por hora.
    Abraços Estevão !!!

    Ponto para o patrão ! hehe… concordo, considerando que o tamanho do campo é fixo o tipo CHAR se torna mais rápido, mas, li em um forum da Oracle que se optar por amazenar um valor que não ocupe tamanho total de seu CHAR ele passará a ter menos performance do que a mesma representação de valor em VARCHAR ” CHAR(10) ocupando 5 é mais lento que um VARCHAR(10) ocupando os mesmos 5″. Acho que tem lógica… por isso o nome VARCHAR… hehe

  6. Fala pessoal…

    Existem SCHEMAs (estrutura lógica dos dados) em banco de dados, que permitem utilizar o tipo “INT(11) ZEROFILL”, onde tal recurso resolveria o questionamento de ZEROS A ESQUERDA. Entretando sou adepto ao uso padronizado conforme mencionado acima. Sem contar nos recursos de objetos de dados com string encapsulada disponível nos bancos mais sofisticados.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s