T-SQL Tuesday – Meu tipo de dado (menos) favorito em SQL: DATE

Olá! Este post é uma contribuição ao T-SQL Tuesday. T-SQL Tuesday é um blogothon mensal, onde a comunidade se reúne para escrever sobre um tópico diferente. O tópico de março  é sobre seu tipo de dados favorito. Brent Ozar é o host do mês.

Eu escrevi esse post em duas versões. Esta que você está lendo em português, e uma em inglês.

Se você trabalha com dados, você provavelmente não tem controle sobre todas suas fontes. Por exemplo, você pode coletar dados de lugares diferentes. Talvez seja o seu trabalho centralizar os dados, e criar padrões para que os dados façam sentido para o seu time. Uma vez que você entendeu seus dados, você pode extrair o real valor deles.

Quando seus dados existem em diferentes sistemas, talvez você não tenha controle sobre a validação que acontece por trás. 

Por exemplo, um dos seus fornecedores podem ser muito específicos sobre os tipos de dados que eles permitem no sistema. Isso significa que quando os dados chegarem até você, você verá algo (idealmente) mais estruturado. Contudo, seus dados podem também prover de um sistema liderado por desenvolvedores que decidiram deixar o usuário “livre” para fazer o que quiser (atenção ao verbo “querer” e não “precisar”, existe uma grande diferença aí).

Dados dos tipos de datas são muito importantes em SQL. Mas para nós humanos, datas podem ser formatadas de diferentes maneiras… Por exemplo, no Brasil, escrevemos datas de um jeito diferente dos Estados Unidos.

  • Brasil: DD/MM/AAAA
  • EUA: MM/DD/AAAA

Em SQL, seu tipo de data é guardado no banco assim: AAAA-MM-DD. Não tem como errar, certo? Errado.

Lembra quando eu disse que você pode ter origens diferentes dos dados e que por isso não tem controle sobre as validações? Vamos pensar no seguinte exemplo:

  • Seus clientes usam um sistema de outro fornecedor, passando os dados para eles
  • O fornecedor usa os dados para fazer o que quer que seja que o sistema faça
  • Eles te enviam os dados com o resultado do projeto
  • Você, um profissional inteligente, tenta carregar os dados no seu sistema. E mais importante, seu sistema é formatado com os tipos de dados que você espera receber. Então, digamos que você queira receber um campo com valores do tipo data, você vai formatar sua tabela para ter um tipo de data.
  • Vamos usar a tabela “ThirdPartyInfo” abaixo como exemplo.

Agora, como você já deve ter imaginado, seu fornecedor não aplicou nenhum tipo de validação para esses tipos de dados. Logo, você pode se deparar com alguns tipos de datas estranhos, como esses:

  • Jan/2021
  • 03-20-18
  • 01-02-03 (onde começar com esse?!)
  • 2022/2
  • Entre outros…

Isso é o que acontece quando tentamos inserir algo que não é uma data, em qualquer uma das colunas do tipo data.

Não importa o método que você use para popularizar essa tabela, você vai receber um erro se você não está passando valores do tipo data para suas colunas do tipo data.

Como evitar problemas como esse

  • Seja honesto com o seu fornecedor sobre a razão de ter os tipos de dados que você precisa, e explique quais são eles. Como explicar? Fazendo aquilo que os profissionais de TI mais odeiam: documentando.
  • Se o fornecedor está relutante com a mudança, fale com seus superiores, mostre para eles cenários onde você tem que gastar seu tempo precioso (e caro) só para arrumar esse erro. Reinforce que isso pode ser evitado se todo mundo estivesse na mesma página sobre os tipos dos dados que vocês compartilham.
  • Se nada acima funcionar, ou você precisar de uma solução temporária enquanto a situação se resolve, você poderia validar os dados do seu lado. Se você fizer um esforço agora, antes do problema, pode parecer mais trabalho, massss o você do futuro vai te agradecer por ter se esforçado antes do problema chegar.

Aprendendo do pior jeito

  • Exemplo da vida real: eu recentemente tive um problema que me custou um certo tempo. Eu recebi um arquivo csv necessário para um relatório, e o arquivo tinha alguns campos de datas. Minha tabela estava esperando receber os campos de datas com valores…de datas. Porém, meu job do carregamento dos dados estava com problemas.
    • Eu tive que dar um passo para trás e tentar encontrar a raiz do problema. Eu pensei que fosse ser algo fácil de conseguir se eu olhasse as entradas mais recentes do arquivo (esse tipo de arquivo era mandado pra nós todos os dias, com as coisas mais recentes atualizadas). Meu problema principal, foi que eu não isolei a coluna de data que estava dando erro. Na verdade, no SQL Server, a mensagem de erro quase sempre é muito genérica, e não me falava qual a coluna. Tudo que eu sabia era que uma string estava tentando ser convertida em data, mas sem sucesso.
    • Meu segundo maior problema foi arrumar tudo que eu encontrei no arquivo, que pudesse de alguma forma estar causando o problema. Alerta spoiler: isso não resolveu meu problema.
    • Eu demorei um tempo para entender que usar a função “ISDATE”, seria uma maneira fácil de procurar por uma coluna que esperava receber um tipo de data, mas que recebia outra coisa.

Em momentos de desespero, esquecemos soluções simples, como esta. 

Observe que o resultado dessa consulta tem um valor do tipo texto. Agora, você pode aplicar essa validação ANTES de carregar os dados na sua tabela de produção, além de usar o mesmo comando para investigar problemas como esse.

Resumindo: eu na verdade gosto do tipo DATE no SQL. Funciona bem, mas o problema real foi que falhamos como humanidade pois nunca concordamos em um único formato para datas. Espero te ajudar de alguma forma!

Se quiser ler mais sobre tipos de dados de datas em SQL, leia aqui (em inglês). 

Você resolveria meu problema de uma maneira diferente? Me conte abaixo nos comentários (:

One thought on “T-SQL Tuesday – Meu tipo de dado (menos) favorito em SQL: DATE”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s