Imagine uma entrevista para uma vaga na área de dados.
O entrevistador pergunta:
“Você sabe SQL?”
Você responde:
“Sim.”
Mas o que exatamente esse “sim” significa?
Que você conhece SELECT?
Que sabe fazer JOIN?
Que já estudou CTE?
Que consegue escrever uma Window Function?
Tudo isso conta.
Mas, para uma empresa, existe uma pergunta ainda mais importante:
O que você consegue resolver utilizando SQL?
Essa diferença muda bastante a forma como podemos pensar nossa preparação para uma vaga.
No trabalho, a pergunta não vem com o comando
Imagine que você acabou de entrar em uma empresa.
Alguém pergunta:
“Quais clientes estão diminuindo suas compras?”
Ninguém acrescenta:
“Utilize
GROUP BYcom uma CTE e depois faça uma comparação.”
Você recebe o problema.
E precisa descobrir o caminho.
Antes de escrever SQL, já existem decisões:
- o que significa “diminuindo”?
- vamos comparar quais períodos?
- quantidade de pedidos ou faturamento?
- onde estão esses dados?
- como os clientes se relacionam aos pedidos?
É aqui que começa uma habilidade profissional importante.
Transformar uma pergunta de negócio em uma pergunta que os dados conseguem responder.
Você consegue entender um banco que nunca viu?
Nos exercícios, normalmente conhecemos as tabelas.
No trabalho, nem sempre.
Você pode encontrar:
cliente
pedido
item_pedido
produto
categoriaE precisar descobrir como tudo se conecta.
Por exemplo:
cliente
↓
pedido
↓
item_pedido
↓
produto
↓
categoriaSaber escrever JOIN é importante.
Mas antes disso você precisa entender:
quais tabelas precisam ser relacionadas para responder à pergunta?
Essa capacidade de explorar um banco desconhecido vale muito.
A empresa também espera que você desconfie do resultado
Imagine que sua consulta execute perfeitamente.
Query executed successfully.Ótimo.
Mas isso não significa que a resposta esteja correta.
Talvez um JOIN tenha multiplicado registros.
Talvez pedidos cancelados estejam sendo considerados.
Talvez você tenha contado itens quando deveria contar pedidos.
Talvez o período esteja errado.
Um profissional que trabalha com dados precisa desenvolver o hábito de perguntar:
Esse número faz sentido?
Executar a query é uma etapa.
Validar o resultado é outra.
Saber SQL também é entender o que cada linha representa
Imagine a tabela pedido.
Cada linha representa:
um pedido.
Depois fazemos um JOIN com item_pedido.
Agora cada pedido pode aparecer várias vezes.
Cada linha passou a representar:
um item do pedido.
Se você não perceber essa mudança e fizer uma soma ou contagem incorreta, pode chegar a um número errado mesmo utilizando uma sintaxe perfeita.
Esse conceito é chamado de granularidade.
E entender granularidade costuma ser muito mais importante no trabalho do que decorar mais uma função.
Você consegue explicar o que fez?
Imagine que você termina uma análise e seu gestor pergunta:
“O que você encontrou?”
Uma resposta ruim seria:
“Eu fiz um
INNER JOIN, depois umGROUP BY, criei uma CTE e utilizeiROW_NUMBER().”
Tecnicamente pode estar tudo certo.
Mas isso não responde à pergunta.
Uma resposta melhor seria:
“Os clientes que reduziram suas compras estão concentrados principalmente em duas categorias. A quantidade de pedidos caiu pouco, mas o valor médio comprado por esses clientes diminuiu bastante.”
Agora temos informação.
A empresa não contratou alguém apenas para escrever consultas.
Ela precisa de alguém que consiga utilizar dados para ajudar a responder perguntas.
Então quais habilidades realmente importam?
Se eu tivesse que resumir, pensaria em seis.
1. Entender a pergunta
Saber exatamente o que precisa ser respondido.
2. Encontrar os dados
Descobrir quais tabelas e colunas possuem as informações necessárias.
3. Entender os relacionamentos
Saber como essas informações se conectam.
4. Construir a consulta
Utilizar SQL para chegar ao resultado.
5. Validar
Conferir se o número realmente faz sentido.
6. Explicar
Transformar o resultado em uma resposta compreensível.
Perceba que escrever SQL é fundamental.
Mas está dentro de um processo maior.
E se eu ainda precisar pesquisar sintaxe?
Normal.
Imagine que você sabe exatamente o que precisa fazer, mas esqueceu como determinada função de data funciona.
Você consulta a documentação.
Resolve.
Isso é muito diferente de receber o problema e não saber por onde começar.
Não lembrar uma sintaxe específica não significa automaticamente que você não sabe SQL.
Uma pergunta mais interessante seria:
Se eu encontrar a sintaxe, consigo entender e validar a solução?
Se a resposta for sim, existe uma base importante aí.
E a inteligência artificial?
Hoje existe mais uma situação.
Você pode pedir para uma IA gerar uma consulta.
Ela entrega SQL em segundos.
Mas alguém ainda precisa verificar:
- os relacionamentos estão corretos?
- a regra de negócio foi entendida?
- existe duplicidade?
- a granularidade faz sentido?
- os filtros estão certos?
- o resultado é confiável?
A IA pode ajudar a escrever SQL.
Mas isso aumenta, e não diminui, a importância de entender o que a consulta está fazendo.
Se você não consegue avaliar a resposta, também não consegue saber quando ela está errada.
Um teste simples
Em vez de perguntar apenas:
“Quantos comandos SQL eu conheço?”
Experimente este teste.
Pegue um banco que você não conhece muito bem e uma pergunta como:
“Quais produtos estão perdendo vendas?”
Veja se consegue:
- definir o que significa “perdendo vendas”;
- escolher os períodos de comparação;
- encontrar as tabelas necessárias;
- entender os relacionamentos;
- construir a consulta;
- validar o resultado;
- explicar o que encontrou.
Se você consegue avançar nesse processo, está desenvolvendo algo muito próximo do que vai precisar no trabalho.
Conclusão
Quando uma empresa pergunta se você sabe SQL, ela pode testar comandos.
E você precisa conhecê-los.
Mas o trabalho não termina na sintaxe.
No dia a dia, você vai receber perguntas.
Algumas incompletas.
Outras ambíguas.
Vai encontrar bancos que nunca viu.
Dados imperfeitos.
Resultados que precisam ser conferidos.
E situações em que nenhuma pessoa vai dizer qual comando utilizar.
Por isso, aprender SQL para o mercado significa evoluir de:
“Eu sei escrever essa query.”
para:
“Eu consigo utilizar SQL para chegar a uma resposta confiável.”
Essa segunda habilidade é muito mais interessante.
Próximo passo
O SQL Simplificado foi estruturado justamente para quem quer avançar além de consultas isoladas e construir uma base mais completa de raciocínio em SQL.
A proposta passa pelo SQL 3C, pelo MVP Dados e pelo Método F.A.S.E., conectando conhecimento técnico, prática e uma forma mais estruturada de resolver problemas.
Porque o objetivo não é apenas dizer em uma entrevista:
“Eu sei SQL.”
É conseguir demonstrar isso quando colocarem um problema e um banco de dados na sua frente.
0 Comentários