O que é SQL e por que ainda é a linguagem mais útil para lidar com dados

“Ainda vale aprender SQL se a IA escreve a consulta para mim?” Vale, e talvez mais do que antes. SQL (Structured Query Language) é a linguagem usada para criar, consultar e alterar dados em bancos relacionais como PostgreSQL, MySQL, SQL Server, Oracle e SQLite. Ela foi padronizada pela ISO e pela ANSI, existe desde os anos 1970 e continua no centro de quase todo sistema que guarda dados de clientes, pedidos ou pagamentos.

A IA gera a consulta em segundos, mas quem precisa saber se ela está certa é você. Uma consulta que “funciona” e devolve o número errado de pedidos do mês é pior do que uma que dá erro, porque ninguém percebe.

SQL descreve o resultado, não o caminho

Essa é a diferença que mais confunde quem vem de Python ou JavaScript. Em SQL você não escreve um laço para percorrer as linhas. Você declara o que quer (“os clientes de Minas que compraram mais de 3 vezes”) e o banco decide como buscar, usando índices e um planejador de consultas.

Por isso SQL se chama linguagem declarativa. E por isso a mesma consulta pode ficar rápida ou lenta dependendo de como as tabelas foram indexadas, sem que uma vírgula do código mude.

Escrevendo suas primeiras consultas SQL em sete passos

Vamos usar um exemplo pequeno: uma loja com as tabelas clientes (id, nome, estado) e pedidos (id, cliente_id, valor, criado_em). Você pode rodar tudo no SQLite, que não exige instalação de servidor.

1. Criar a tabela.

   CREATE TABLE clientes (
     id INTEGER PRIMARY KEY,
     nome TEXT NOT NULL,
     estado CHAR(2)
   );

2. Inserir dados.

   INSERT INTO clientes (nome, estado) VALUES ('Ana', 'MG'), ('Bruno', 'SP');

3. Ler com filtro.

   SELECT nome FROM clientes WHERE estado = 'MG';

4. Ordenar e limitar.

   SELECT * FROM pedidos ORDER BY valor DESC LIMIT 10;

5. Juntar tabelas com JOIN.

   SELECT c.nome, p.valor
   FROM pedidos p
   JOIN clientes c ON c.id = p.cliente_id;

6. Agrupar e somar.

   SELECT c.estado, COUNT(*) AS qtd, SUM(p.valor) AS total
   FROM pedidos p
   JOIN clientes c ON c.id = p.cliente_id
   GROUP BY c.estado
   HAVING COUNT(*) > 5;

7. Atualizar e apagar com WHERE.

   UPDATE clientes SET estado = 'RJ' WHERE id = 2;
   DELETE FROM pedidos WHERE id = 37;

Com esses sete comandos você resolve boa parte do trabalho diário. O tutorial de SQL da documentação do PostgreSQL segue uma progressão parecida, com tabelas de clima e cidades, e é gratuito e muito bem escrito.

Onde as consultas SQL costumam dar errado

Cada passo acima tem um tropeço clássico. Conhecer de antemão economiza horas de depuração.

UPDATE e DELETE sem WHERE

Esquecer o WHERE num DELETE apaga a tabela inteira. Hábito que salva: escreva primeiro um SELECT com o mesmo filtro, verifique as linhas e só então troque por DELETE. Em produção, rode dentro de uma transação (BEGIN) para poder desfazer.

JOIN que multiplica linhas

Se um cliente tem 4 pedidos e 3 endereços, juntar as três tabelas sem cuidado gera 12 linhas para ele. A soma dos pedidos fica três vezes maior e ninguém entende o motivo. Sempre que um total parecer alto demais, desconfie do JOIN.

NULL não é zero nem texto vazio

WHERE estado = NULL nunca retorna nada. O certo é WHERE estado IS NULL. E COUNT(coluna) ignora os nulos, enquanto COUNT(*) conta todas as linhas, uma diferença que muda relatórios.

WHERE versus HAVING

WHERE filtra linhas antes de agrupar; HAVING filtra grupos depois. Querer “estados com mais de 5 pedidos” e escrever WHERE COUNT(*) > 5 dá erro de sintaxe.

Por que a mesma consulta SQL fica lenta de repente

Com 500 pedidos, tudo é instantâneo. Com 2 milhões, a tela que listava “pedidos do cliente” começa a levar oito segundos, e o código não mudou nada.

O motivo quase sempre é a falta de um índice. Sem ele, o banco lê a tabela inteira para achar os pedidos de um cliente (a famosa varredura completa). Com um índice na coluna usada no filtro, ele vai direto às linhas certas, como o índice remissivo de um livro.

CREATE INDEX idx_pedidos_cliente ON pedidos (cliente_id);

Para saber se o banco está usando o índice, peça o plano de execução com EXPLAIN (no PostgreSQL, EXPLAIN ANALYZE roda a consulta e mostra o tempo real de cada etapa). Se aparecer Seq Scan numa tabela grande, é ali que mora a lentidão.

Índice não é de graça: cada um ocupa espaço e deixa INSERT e UPDATE um pouco mais lentos. A regra prática é indexar as colunas que aparecem com frequência em WHERE, JOIN e ORDER BY, e não sair criando índice em tudo.

Outro clássico de lentidão é o SELECT * em tabela larga, trazendo vinte colunas quando a tela usa três. Peça só o que vai usar: a consulta trafega menos dados e fica mais fácil de ler no futuro.

Um SQL, vários sotaques

O padrão é o mesmo, mas cada banco tem dialeto próprio. Limitar resultados, por exemplo:

Na prática, 90% do que você aprende num banco funciona no outro. Datas, funções de texto e tipos de dados são onde os dialetos mais divergem. A referência de sintaxe SQL entendida pelo SQLite mostra bem o que é comum e o que é específico.

Onde o SQL aparece no trabalho de devs e analistas

• Back-end: mesmo usando ORM (Prisma, Hibernate, Django ORM, Eloquent), você vai ler o SQL gerado para entender por que uma tela está lenta.
• Análise de dados: ferramentas de BI e planilhas conectadas ao banco dependem de consultas para alimentar painéis. Veja algumas em ferramentas de análise de dados para devs.
• Suporte e operação: descobrir por que o pedido 4512 sumiu quase sempre começa com um SELECT.
• Concursos e entrevistas: SQL é cobrado com frequência em provas de TI e em testes técnicos para vagas júnior.
• Segurança: concatenar texto do usuário dentro da consulta abre espaço para SQL injection. Use sempre parâmetros (? ou $1) no lugar de montar a string na mão.

Treinar SQL com dados que você conhece

O próximo passo prático é sair dos exemplos genéricos. Exporte o extrato do seu banco em CSV, os gastos do mês ou a lista de jogos do seu campeonato preferido, importe no SQLite e faça perguntas reais: quanto gastei com delivery por mês? Qual time marcou mais gols em casa? Responder perguntas que você mesmo tem fixa a linguagem muito mais rápido do que decorar sintaxe.

Um roteiro de quatro semanas que costuma funcionar: na primeira, só SELECT, WHERE e ORDER BY; na segunda, GROUP BY e funções de agregação; na terceira, JOIN entre duas e três tabelas; na quarta, crie suas próprias tabelas, índices e rode EXPLAIN nas consultas que escreveu. Ao fim do mês, você lê com segurança o SQL que um ORM ou uma IA gerar.

Quando aparecerem termos como chave primária, índice ou ORM, o glossário de programação do portal explica cada um em poucas linhas.