
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 (: