Houve um tempo na história da tecnologia de informação em que dados eram tratados exclusivamente como cadeias de caracteres de comprimento fixo.

O tempo passou, a tecnologia evolui e as empresas perceberam que era importante que houvesse algum tipo de diferenciação do domínio de valores aceitos por um campo ou variável. E então foi criado o conceito de tipos de dados, que permitiam distinguir campos que receberiam números, caracteres, datas, etc.

Eu não sei dizer quem inventou os tipos de dados. Fiz uma rápida pesquisa na internet e não encontrei nenhuma informação conclusiva. E também não consegui confirmar a minha suposição de que tipos de dados existem na linguagem SQL desde a sua criação. Mas isso não é relevante para minha argumentação.

A questão aqui é que os tipos de dados foram criados em razão de uma necessidade. Tendo isso em mente, eu me pergunto por que existe tanto arquiteto que cria modelo de banco de dados usando CHAR ou VARCHAR em tudo que é campo da tabela.

Na minha opinião, isso é uma falta de cuidado imperdoável. O fato do arquiteto não conhecer o domínio de um certo campo não justifica o desprezo por uma pesquisa do tipo “pra que raios serve este campo?”. Esta pergunta simples pode dar uma boa dica de qual o domínio e, consequentemente, qual o tipo de dados a ser usado.

Tipificação de dados é tão relevante que praticamente todo SGBD permite que criemos nossos próprios tipos de dados, os chamados UDT (User-Defined Data Type).

Usar um tipo de dados adequado obviamente garante uma melhor qualidade dos dados, pelo simples fato de sabermos que erros de digitação, por exemplo, podem ser detectados antes da inserção do registro na tabela.

Já vi muito sistema tratando tudo que é tipo de dados como se fossem caracteres e eu simplesmente não vejo nenhuma justificativa que me convença a usar tipos de dados genéricos (digamos, CHAR e VARCHAR) para qualquer campo. Temos obrigação de saber para que serve cada campo do modelo de banco de dados e quais os domínios destes campos.

Se não tomarmos estes cuidados, provavelmente vamos causar problemas para quem consome os dados, ou seja, quem gera relatórios e/ou analisa estes dados.

E isso acontece com mais frequência do que imaginamos. Lembro-me de quando eu trabalhei numa multinacional envolvido na construção de um projeto de Business Intelligence (BI) que buscava dados no sistema de gestão da empresa. Este era um sistema de gestão de primeira linha no mercado. Mesmo assim, frequentemente tínhamos problemas na carga de dados (ETL), porque quase vários campos que importávamos eram tratados como cadeias de caracteres, independente de serem números, datas ou qualquer outra coisa.

Para ilustrar o problema com tipos de dados, vejamos o caso de campos de datas que são definidos como cadeias de caracteres. Este é um caso especialmente complicado. Em primeiro lugar, campo CHAR ou VARCHAR não valida o formato data: MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD seriam todos aceitos.

Mesmo que sua aplicação force o uso de um formato específico, qualquer erro de digitação do usuário vai para dentro do banco de dados. Vamos considerar que a aplicação valida o formato e só são aceitos valores do tipo MM/DD/YYYY. Se o usuário digitar “1A/31/2013”, “30/12/2013” ou “12/31/1000”, todos os três valores serão aceitos, mas nenhum deles seria entendido como data numa conversão de dados. Lembre-se que a maioria dos SGBDs aceitam datas no intervalo entre 01/janeiro/1753 a 31/dezembro/9999. Então, o primeiro valor seria recusado porque contém um caracter alfanumérico, o segundo porque mostra o número 30 onde se esperava o mês e o terceiro porque informa o ano 1000, que está fora da faixa de valores aceita.

Ao invés de definir todas as validações de dados através de regras de negócio na aplicação, é mais inteligente usar tipos de dados adequados tanto para as variáveis usadas na aplicação como também nos campos das tabelas. Devemos sim esperar que toda inclusão e/ou alteração de dados seja feita via aplicação. Mas é mais prudente garantir que o SGBD também faça as validações de domínio, porque  eventualmente podem acontecer alterações de dados diretamente no banco através de instruções INSERT e UPDATE.

Resumindo: não é por acaso que existem vários tipos de dados disponíveis no seu banco de dados. Saiba que tipo de informação é armazenada em cada campo do seu modelo e escolha adequadamente seus tipos de dados. Isso vai ajudar a ter dados mais confiáveis.