Licao 10.1 · Tempo de leitura: ~9 min

Esta licao apresenta os fundamentos para escrever codigo SQL de qualidade, facil de ler e manter. Voce vai aprender padroes de formatacao, regras de nomeacao de objetos e uso de comentarios. Vamos ver como tornar consultas complexas mais claras para colegas e para voce no futuro. Ao final desta licao, voce conseguira organizar scripts SQL de forma profissional e consistente.

Licao 10.1: Boas praticas para codigo SQL legivel e sustentavel

No modulo anterior, estudamos ferramentas avancadas como views e tabelas temporarias. Agora que suas consultas estao ficando maiores e mais complexas, a qualidade do codigo passa a ser prioridade. No trabalho real de analise e desenvolvimento, o SQL e lido muito mais vezes do que escrito.

Codigo bem estruturado reduz erros, simplifica depuracao e economiza tempo de toda a equipe. Nao e apenas uma questao estetica: e uma habilidade essencial para qualquer desenvolvedor SQL ou analista de dados.

Por que o estilo de codigo importa

Quando uma consulta tem 5-10 linhas, sua logica costuma ser clara. Mas ao trabalhar com relatorios complexos com varios JOIN, subconsultas ou CTE, o codigo pode ficar carregado e dificil de entender, ate para quem escreveu.

Seguir padroes ajuda voce a:

• Encontrar erros mais rapido: filtros incorretos ou JOIN ausente ficam mais visiveis.
• Escalar solucoes: codigo estruturado e mais facil de expandir com novos campos e regras.
• Trabalhar em equipe: colegas conseguem revisar e manter scripts com menos atrito.

Formatacao e indentacao

Um estilo consistente de formatacao e a base da legibilidade. SQL nao e sensivel a espacos ou caixa de letras, mas existem convencoes amplamente aceitas.

Caixa de palavras-chave

Uma boa pratica e escrever palavras-chave SQL (SELECT, FROM, WHERE, JOIN, GROUP BY) em maiúsculas. Isso separa visualmente comandos do banco dos nomes de tabelas e colunas.

-- Ruim
select name, price from products where category_id = 1;

-- Melhor
SELECT name, price
FROM products
WHERE category_id = 1;

Quebras de linha e indentacao

Cada clausula principal deve comecar em nova linha. Se SELECT ou GROUP BY listar muitas colunas, coloque cada uma em uma linha.

SELECT 
    customer_id,
    first_name,
    last_name,
    email
FROM customer
WHERE active = 1
ORDER BY last_name;

Convencoes de nomeacao

Escolher bons nomes para tabelas, colunas e variaveis e essencial para manter o codigo claro.

Minusculas e snake_case

Em SQL, uma convencao comum e usar minusculas com underscore para separar palavras. Muitos SGBDs normalizam identificadores de formas diferentes, e snake_case reduz confusao.

• Ruim: CustomerOrders, TotalAmount
• Melhor: customer_orders, total_amount

Prefixos por tipo de objeto

Algumas equipes usam prefixos para identificar rapidamente o tipo de objeto.

Exemplos:

• v_ para views: v_active_customers
• tmp_ para tabelas temporarias: tmp_monthly_report
• t_ para tabelas base (menos comum)

-- Fica claro que os dados vem de uma view preparada
SELECT * 
FROM v_customer_payment_summary
WHERE total_amount > 100;

Nomeacao e aliases

Nomes e aliases claros deixam a consulta autoexplicativa.

Aliases de tabela claros

Use aliases curtos, mas significativos, especialmente com JOIN. Evite t1, t2, a, b.

-- Nao claro
SELECT 
    t1.name, 
    t2.amount
FROM table_a t1
JOIN table_b t2 ON t1.id = t2.ref_id;

-- Claro
SELECT 
    c.first_name, 
    p.amount
FROM customer c
JOIN payment p ON c.customer_id = p.customer_id;

Aliases claros para campos calculados

Sempre nomeie agregacoes e colunas calculadas de forma explicita. Uma coluna count(*) em relatorio parece pouco profissional.

SELECT 
    category_id,
    COUNT(*) AS total_films_in_category,
    AVG(replacement_cost) AS average_replacement_cost
FROM film
GROUP BY category_id;

Comentarios no codigo SQL

Comentarios explicam por que uma parte da logica existe quando a intencao nao e obvia.

• Comentario de linha (--): para explicar filtros ou formulas especificas.
• Comentario em bloco (/* ... */): para descrever objetivo do script, autor e data.

/*
  Script: Monthly active customer spending
  Author: Ivanov I.
  Date: 2026-04-16
*/

SELECT 
    customer_id,
    SUM(amount) AS monthly_spent
FROM payment
WHERE payment_date >= '2026-01-01' -- Filter from start of year
  AND payment_date < '2026-02-01'
GROUP BY customer_id;

Exemplo pratico: organizando uma consulta "suja"

Compare uma consulta dificil de ler com uma versao sustentavel.

Antes (dificil de ler):

select f.title,c.name,count(r.rental_id) from film f join film_category fc on f.film_id=fc.film_id join category c on fc.category_id=c.category_id join inventory i on f.film_id=i.film_id join rental r on i.inventory_id=r.inventory_id group by f.title,c.name having count(r.rental_id)>30 order by count(r.rental_id) desc;

Depois (facil de manter):

SELECT 
    f.title,
    c.name AS category_name,
    COUNT(r.rental_id) AS rental_count
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c       ON fc.category_id = c.category_id
JOIN inventory i      ON f.film_id = i.film_id
JOIN rental r         ON i.inventory_id = r.inventory_id
GROUP BY f.title, c.name
HAVING COUNT(r.rental_id) > 30
ORDER BY rental_count DESC;

Observacao: na segunda versao, estrutura de relacionamentos, agregacoes e filtros ficam claros imediatamente.

Pontos principais desta licao:

• Escreva palavras-chave SQL em maiusculas para destacar a estrutura da consulta.
• Use quebras de linha e indentacao para facilitar leitura e revisao.
• Use aliases claros para tabelas e campos calculados.
• Aplique convencoes consistentes, como snake_case, para tabelas e colunas.
• Comente regras de negocio nao obvias e filtros complexos.
• Mantenha um padrao comum na equipe para acelerar revisao, depuracao e evolucao.

Perguntas frequentes

Palavras-chave SQL precisam sempre estar em maiusculas?

Nao ha exigencia tecnica. O SGBD interpreta minusculas tambem. Mas um padrao consistente (SELECT, FROM, WHERE, JOIN) melhora legibilidade.

Quando comentarios em SQL sao realmente uteis?

Quando a logica nao e obvia: regras de negocio, filtros incomuns e restricoes tecnicas. Se o codigo ja esta claro, evite comentarios desnecessarios.

O que pesa mais na manutencao: formatacao ou nomeacao?

Ambos. A formatacao mostra estrutura; a nomeacao torna a intencao clara sem explicacoes extras.

Perguntas de entrevista

Quais caracteristicas definem SQL sustentavel?

SQL sustentavel tem formatacao consistente, nomes claros, aliases significativos e comentarios curtos em partes nao obvias. Isso facilita revisao e evolucao.

Por que nomeacao ruim vira problema para a equipe?

Nomes ambigüos atrasam revisoes e aumentam risco de erro em mudancas. Bons nomes reduzem carga cognitiva.

Como voce melhoraria uma consulta SQL confusa?

Primeiro separaria em blocos logicos (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) com formatacao consistente. Depois ajustaria aliases e nomes de campos calculados.

Na proxima licao, vamos para a otimizacao tecnica e aprender a escrever consultas SQL nao apenas limpas, mas tambem rapidas.

-> Licao 10.2: Escrita de consultas SQL eficientes