Voc√™ precisa de SQL para trabalhar na √°rea de dados?

Ilustra√ß√Ķes por Camila Henrique

Eu quis falar sobre isso pois eu vejo muitas d√ļvidas e uma falta de dire√ß√£o de pessoas que est√£o come√ßando em TI ou pensando em trocar de carreira. A resposta r√°pida para a pergunta ‚Äúeu preciso saber SQL para conseguir um trabalho na √°rea de dados?‚ÄĚ, √© sim, precisa. Nos pr√≥ximos par√°grafos eu te explico por que eu penso isso.

√Č f√°cil se perder no meio de tantas linguagens de programa√ß√£o e metodologias de projeto que √†s vezes o b√°sico fica pra tr√°s. Eu acredito que ter uma boa funda√ß√£o pode te abrir portas que antes voc√™ n√£o veria. Eu tenho certeza que SQL √© uma grande skill pra se ter na √°rea de dados.

Os data jobs est√£o em alta h√° alguns anos. Existe muita especula√ß√£o sobre o que uma pessoa da √°rea faz (e realmente, isso pode variar muito). Por√©m, existe uma habilidade que sempre aparece nas descri√ß√Ķes de vagas de trabalho. Voc√™ consegue encontr√°-la abaixo nos exemplos?

This image has an empty alt attribute; its file name is image.png
Linkedin, Julho 2021

Linkedin, Julho 2021

Linkedin, Julho 2021

O SQL sempre está em demanda para muitas vagas. Porque faz parte dos básicos da área. Quando você domina os básicos, você tem grandes chances de prosperar. Você pode aprender coisas ótimas sobre a área de dados, mas no fim, em algum momento você vai precisar lidar com ele: um banco de dados. E adivinha: SQL é justamente como nos comunicamos com os bancos de dados, sua própria língua (eu acho isso lindo, pare de me julgar!).

Eu estou trabalhando em uma s√©rie de posts dedicados √† pessoas que gostariam de aprender SQL do zero. Meu foco ser√° o produto da Microsoft, o MS SQL Server. Eles tem uma ‚Äúvers√£o” de SQL s√≥ para esse banco de dados, √© o T-SQL. Eu espero compartilhar meu conhecimento com voc√™ e quem sabe eu n√£o ajude algu√©m no meio do caminho. Esse √© meu jeito de retribuir para a comunidade ūüôā

Perguntas ou sugest√Ķes, meus coment√°rios est√£o sempre abertos!

Se você quiser ler este mesmo post em inglês, leia aqui.

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

T-SQL Tuesday – My (least) favorite SQL data type: DATE

Hello! This post is a contribution to T-SQL Tuesday. T-SQL Tuesday is a monthly blogothon where we get together and write about a different topic. March’s topic was to blog about you favorite data type, hosted by Brent Ozar.

I wrote two versions of this post. This one you’re reading in English, and this one in Portuguese.

If you work with data, you probably do not have control over all the data sources you need. What I mean, is that for example, you may receive data from different places. Perhaps it’s your job to centralize and standardize it the best you can, so that it makes sense to your team. Once you understand the data, value can be extracted from it.

When your data comes from different systems, it’s likely you will not have control over the data’s validation. For example, one of you vendors may be very specific about the data types allowed into their systems, which means when the data gets to you, you’ll see something (ideally) more structured. However, your data may also be handled by a group of fed up developers who decided they will allow everything the user wants (special attention to the the verb there being want instead of need, big difference).

Date data types are really important and used in SQL. But for humans, dates can be formatted in some ways… For example, I’m from Brazil, and the way we write our dates is different from the US.

  • Brazil: DD/MM/YYYY
  • US: MM/DD/YYYY

In SQL, your date type stores data like this: YYYY-MM-DD. No room for mistakes, right? Bam, Wrong.

Remember when I said you may have different data sources and you can’t control their data type validations? Let’s think of the following example:

  • Your clients use a 3rd part system
  • The 3rd party uses the data to do whatever it is their system does
  • They send you that data with the results of your project
  • You, a smart data person, tries to load the data into your system. Most importantly, your system is formatted with the data types you expect to receive. So, for example, if you expect a field with a date value, you’ll format your table to have a date type column.
  • Let’s use the table “ThirdPartyInfo” as an example.

Now, as should have assumed by now, your third party did not applied any data validation to the date types. Hence, you may get some crazy “dates”, like this:

  • Jan/2021
  • 03-20-18
  • 01-02-03 (where to even begin with this one?!)
  • 2022/2
  • and many others….

Here’s what happens when you try to insert something that’s not a date, into any of the date columns:

It does not matter the method you’ll use to input data to your table, you’ll get an error if you’re not passing date values to your date types columns.

How can you avoid issues like this

  • Be open to your vendor about why this is important to your data, and explain to them your tables data type. How? Documenting, the thing IT people hate most.
  • If the vendor is pushing back, talk to your superiors, and show them a scenario in which you need to spend your precious (expensive) time to fix this mishap. Enforce this could be avoided if everyone were on the page about the data types for the data you share.
  • If nothing above works, or you need a temporary solution, you could validate the data on your end too. More work upfront, but your future self will thank you for putting this effort now.

Learning it the hard way

  • Real life example: I recently had an issue that cost me a lot of time. I had received a csv I needed for reporting, and the file had a few date fields. My table, was expecting date types to come in all the fields, but I was getting errors on my data loading job.
    • I had to take a step back and find where the issue was. I thought it would be easy to find, by checking the most recent info that got into the system (this was a daily file we received), and so I started looking for the issue. My main mistake, was that I did not isolate the date column that was giving me an error. In the SQL Server, the error message was really vague, I could only tell there was a string trying to be converted to date and I had several different date fields in my table.
    • My second big mistake was fixing everything I found on the source file, and I thought was wrong and causing the issues. Spoiler alert: it wasn’t.
    • It took me some time to realize that “ISDATE” was an easy way to search for a column that is expecting a date type, but received something else instead:
In desperate times, we may be blind by stress and not think about simple things, like this.

You see that the return to that query has the string value. Now, you could apply this kind of check as a validation before you load data into your production table, and also use it to troubleshoot issues like mine.

With all that being said, I actually like the DATE data type in SQL. It works great, the real issue is that we as humanity never agreed on a single date format. Sigh. I hope this helps!

If you want you can read more about the Date types here: Date types in SQL

Would you solve my problem in a different way? Tell me how below in the comments (: