SQL: o que é e por que todo banco de dados usa

O pedido chega sempre no mesmo formato. Alguém de vendas quer a lista de clientes que compraram nos últimos noventa dias e gastaram acima de cinco mil reais. O dado existe, está no sistema, e nenhum relatório pronto tem esse corte.

Quem resolve abre uma tela de consulta e escreve seis linhas de SQL. Em alguns segundos a lista aparece, e quem olha de fora costuma achar que viu programação pesada.

SQL é a linguagem que os bancos de dados relacionais entendem, e ela foi desenhada para uma tarefa só: descrever qual recorte de dados você quer. Como chegar nesse recorte é decisão do banco, não sua.

Você escreve o resultado que quer, e quem escolhe o caminho de busca é o planejador do banco. Duas consultas com o mesmo texto podem responder na hora ou travar por minutos, e a diferença costuma estar no índice que existe ou não existe por baixo.

O que SQL faz e o que o banco faz por você

A diferença entre linguagem declarativa e linguagem imperativa explica todo o resto. Numa linguagem imperativa você descreve os passos: abra o arquivo, leia a primeira linha, compare com o valor, guarde se bater, siga para a próxima. Numa consulta você descreve apenas a condição que as linhas precisam satisfazer.

Quem transforma essa descrição em passos é o planejador de consultas. A documentação do PostgreSQL descreve o trabalho dele em uma frase direta. O otimizador examina cada plano de execução possível e escolhe o que deve rodar mais rápido, segundo a documentação do planejador. Ele monta caminhos alternativos, estima o custo de cada um e passa o mais barato para o executor.

As alternativas são concretas. Varrer a tabela inteira é sempre uma opção, e um plano de varredura sequencial é sempre criado. Usar um índice entra na disputa quando a condição da consulta casa com a chave de um índice existente. Para juntar duas tabelas, o mesmo documento lista três estratégias: laço aninhado, junção por ordenação e junção por tabela de dispersão.

É por isso que criar um índice muda o tempo de resposta sem mudar uma vírgula do seu texto. E é por isso que ninguém consegue olhar uma consulta num editor e dizer se ela é rápida. A resposta depende do volume da tabela, das estatísticas coletadas e dos índices que alguém criou meses antes.

O vocabulário mínimo: quatro peças resolvem quase tudo

A lista de comandos é longa, e a maior parte dos relatórios cabe em quatro ideias.

A primeira escolhe as colunas que você quer ver, com SELECT, e a tabela de onde elas vêm, com FROM. A segunda filtra linhas com WHERE: a condição vira um teste aplicado a cada linha candidata, e é aqui que um índice costuma entrar em cena. O filtro corta linhas, a lista de colunas corta colunas, e misturar os dois papéis é a confusão mais comum de quem está começando.

A terceira junta tabelas com JOIN. Cliente fica numa tabela, pedido fica em outra, e a chave que liga as duas é o que permite perguntar quanto cada cliente comprou. Essa separação por tabelas vem direto das decisões de modelagem de dados, que definem onde cada informação mora.

A quarta agrupa com GROUP BY e resume com funções como COUNT, SUM e AVG. É o equivalente textual da tabela dinâmica da planilha: escolha o que vira linha, escolha o que vira soma, pronto. Quem já monta tabela dinâmica entende essa parte em uma tarde.

Com essas quatro peças e um ORDER BY no fim, dá para montar a maior parte dos recortes que um gestor pede.

SQL, banco relacional e SGBD são três coisas diferentes

A confusão mais frequente mistura a linguagem com o programa que a interpreta. SQL é a linguagem. Banco relacional é o modelo de dados, aquele em que a informação fica em tabelas com linhas, colunas e chaves. SGBD é o software que guarda esses dados e aceita comandos, como PostgreSQL, MySQL, SQL Server, Oracle e SQLite.

A consequência é boa para quem está aprendendo: o que você aprende de linguagem migra entre bancos. Um SELECT com WHERE e JOIN escrito para MySQL roda praticamente igual no PostgreSQL. O que muda é a borda, e a borda é maior do que parece.

Há outra distinção útil, sobre os dados que entram nesse modelo. Tabela com coluna tipada é o exemplo clássico de dado organizado, e boa parte do que uma empresa produz não tem essa forma, assunto que já tratei em dados estruturados e não estruturados. Formatos flexíveis como JSON hoje convivem com o modelo relacional, e os bancos passaram a aceitar colunas desse tipo.

Por que existe padrão ANSI e dialeto ao mesmo tempo

A linguagem é normatizada pela ISO, e a revisão mais recente é a de 2023, chamada ISO/IEC 9075:2023. A própria documentação do PostgreSQL dá o número que resume a situação. Das 177 funcionalidades obrigatórias para conformidade total com o núcleo, o PostgreSQL atende a pelo menos 170. Nenhum banco de dados em versão atual declara conformidade total com esse núcleo.

Os fornecedores também somam extensões por escolha deliberada. O manual do MySQL diz que um dos objetivos é seguir em direção à conformidade com a norma sem sacrificar velocidade ou confiabilidade. A mesma página afirma que a equipe não tem medo de acrescentar extensões quando isso aumenta a usabilidade do servidor. No mundo Microsoft o dialeto tem nome próprio, Transact-SQL, e a documentação da empresa afirma que todas as ferramentas e aplicações que conversam com um banco dele fazem isso enviando comandos T-SQL.

Para quem usa, o efeito é simples de prever. O núcleo da linguagem viaja entre bancos. Funções de data, limite de linhas, tratamento de texto, tipo monetário e sintaxe de paginação mudam de nome e de comportamento. Copiar uma consulta de um fórum sem olhar qual banco o autor usava é a origem de boa parte dos erros de sintaxe.

SQL contra NoSQL: o que muda em cada escolha

A oposição virou rótulo de marketing, o que atrapalhou o entendimento. NoSQL reúne famílias bem diferentes entre si: documento, chave e valor, coluna larga e grafo. O que elas têm em comum é abrir mão de parte das garantias do modelo relacional em troca de outra coisa, em geral escala horizontal ou liberdade de formato.

A escolha vira fácil quando você olha a pergunta que vai fazer todo dia. Dado com muita relação entre entidades e relatório que cruza entidades pedem o modelo relacional. Documento que muda de forma a cada cliente, ou volume que não cabe num servidor só, justificam os outros.

Onde um gestor esbarra em SQL sem virar programador

Quase toda ferramenta de dados aceita consulta direta em algum ponto do caminho, e é onde a conversa sobre dados sai do slide e vira número.

Em ferramenta de Business Intelligence, o painel bonito é a camada de cima. Embaixo existe uma consulta que alguém escreveu, e quando o número do painel discorda do número do sistema, a divergência quase sempre está num filtro ou numa junção dessa consulta. Saber ler o texto já resolve metade das discussões.

Os outros pontos de contato são parecidos: relatório customizado de ERP, exportação agendada para planilha, trabalho de Data Analytics feito por terceiro e até consulta de verificação durante uma auditoria. Em todos eles, quem consegue ler a consulta consegue conferir a resposta.

Como aprender SQL o suficiente para parar de pedir relatório

1. Instale um banco pequeno na sua máquina. SQLite resolve: é um arquivo único, sem servidor para configurar, e aceita a mesma linguagem. Você não precisa pedir ambiente para a TI no primeiro dia.
2. Carregue dados seus. Exporte uma planilha de verdade do seu trabalho e importe. Aprender sobre tabela de exemplo de loja fictícia desmotiva na segunda semana.
3. Escreva as quatro peças na ordem. Primeiro escolher colunas, depois filtrar, depois juntar duas tabelas, depois agrupar e somar. Cada passo em cima do anterior, sempre com um resultado visível na tela.
4. Confira cada resposta contra uma fonte que você já conhece. Rode a consulta e compare com o total do relatório oficial do mês. Divergência aponta exatamente onde o seu filtro está errado.
5. Peça o plano de execução antes de reclamar de lentidão. O comando EXPLAIN mostra o caminho que o banco escolheu. Ver uma varredura sequencial numa tabela grande ensina mais sobre índice que qualquer artigo.
6. Decore qual banco você está usando. Antes de copiar consulta da internet, confirme o produto e a versão. Dialeto trocado responde por uma parte grande desses erros.

A linguagem é mais velha que quase todos os sistemas que a usam hoje. E segue sendo a forma padrão de perguntar coisas a um banco relacional. A ideia central envelheceu bem: descrever o recorte é trabalho de quem pergunta, achar o caminho é trabalho da máquina.

Isso tem um efeito direto para quem decide. Quando alguém pede mais servidor para resolver relatório lento, a primeira pergunta é qual plano de execução o banco escolheu, e a resposta costuma apontar para um índice que ninguém criou. Das 177 funcionalidades obrigatórias do núcleo da norma de 2023, o PostgreSQL atende a pelo menos 170, e nenhum banco em versão atual declara atender todas.