Formatador SQL

Formatador SQL - Formatar SQL Online

Ferramenta de formatador SQL online que ajuda você a formatar e embelezar consultas SQL.

Qual é o estilo padrão de formatação SQL?

Não existe um padrão oficial único, mas a convenção mais adotada segue o estilo de Joe Celko (do livro SQL for Smarties): palavras-chave em MAIÚSCULAS, identificadores em minúsculas ou snake_case, uma cláusula por linha (SELECT, FROM, WHERE, etc.), colunas indentadas sob SELECT e joins alinhados sob FROM. Ferramentas modernas como sqlfluff, sql-formatter e pgFormatter implementam variações. O próprio padrão ISO/IEC 9075 SQL só define sintaxe e semântica, não estilo. A documentação de cada fornecedor sugere diretrizes de estilo: o wiki do PostgreSQL tem uma página de code style e o T-SQL do SQL Server tem guias da Microsoft Press. A consistência dentro da equipe importa mais que o estilo específico escolhido.

Por que usar MAIÚSCULAS para palavras-chave SQL?

Palavras-chave em maiúsculas (SELECT, FROM, WHERE, JOIN) separam visualmente a sintaxe SQL dos identificadores definidos pelo usuário (nomes de tabelas e colunas), tornando as consultas legíveis num relance. A convenção surgiu nos mainframes dos anos 1970 onde cartões perfurados usavam maiúsculas de qualquer jeito. Parsers SQL modernos são case-insensitive para palavras-chave conforme o padrão ISO 9075, então `select` funciona identicamente a `SELECT`. Algumas equipes hoje preferem minúsculas por velocidade de digitação e estética moderna — a documentação do Carbon (IBM) e a API do Stripe usam minúsculas. Ferramentas como sqlfluff permitem ambos com a config `--rules L030`. A escolha é puramente estilística; escolha uma e aplique de forma consistente.

Como formatar JOINs para melhor leitura?

Cada JOIN fica em sua própria linha, com a cláusula ON indentada ou na linha seguinte. O estilo moderno alinha JOINs sob FROM e agrupa condições verticalmente:
```
SELECT u.name, o.total
FROM users AS u
JOIN orders AS o ON o.user_id = u.id
LEFT JOIN profiles AS p ON p.user_id = u.id
WHERE o.created_at > '2024-01-01';
```
A sintaxe explícita JOIN (padrão ANSI SQL-92) é preferível ao FROM com vírgulas implícitas porque separa limpamente as condições de join dos filtros e evita produtos cartesianos acidentais. Os planos EXPLAIN ANALYZE do PostgreSQL otimizam ambas as formas identicamente, mas a diferença de legibilidade se acumula em consultas com 5+ tabelas.

O que é minificação SQL e vale a pena?

A minificação SQL remove espaços, comentários e quebras desnecessárias para reduzir o tamanho da string da consulta. Útil ao embutir SQL em código JavaScript/TypeScript que vai para clientes, em parâmetros de URL para ferramentas de analytics ou em payloads JSON onde cada byte importa. Ferramentas como `sql-minifier-cli` e `sqlmin` fazem isso. Ressalvas: SQL minificado é difícil de depurar e revisar, e a maioria dos servidores de banco de dados o parseia identicamente — não há ganho de desempenho em tempo de execução. Sistemas de build modernos (Vite, Webpack) frequentemente minificam SQL embutido automaticamente. Mantenha o SQL fonte formatado para humanos, minifique apenas em build para deploy de produção.

Como prevenir injeção SQL em consultas formatadas?

Use sempre consultas parametrizadas (prepared statements) em vez de concatenação de strings: `SELECT * FROM users WHERE id = $1` com `$1` vinculado como parâmetro, nunca `SELECT * FROM users WHERE id = ' + userId`. A OWASP SQL Injection Prevention Cheat Sheet (2023) e a CWE-89 listam isso como defesa primária. Todo SDK moderno suporta: `cursor.execute(sql, (id,))` do psycopg, `PreparedStatement.setInt(1, id)` do JDBC, `client.query(text, values)` do pg do Node.js. O estilo de formatação não tem impacto em segurança, mas nunca inclua entrada de usuário diretamente em strings SQL. Stored procedures e ORMs adicionam camadas de defesa extras, mas parametrização correta é a base.

O que são Common Table Expressions (CTEs) e como formato?

CTEs são subconsultas nomeadas definidas com a palavra-chave WITH, introduzidas no ISO SQL:1999 e suportadas por PostgreSQL, MySQL 8.0+, SQL Server e Oracle. Melhoram a legibilidade quebrando consultas complexas em passos nomeados e sequenciais. Formate cada CTE em seu próprio bloco, separadas por linhas em branco:
```
WITH active_users AS (
SELECT id, name FROM users WHERE last_login > NOW() - INTERVAL '30 days'
),
order_totals AS (
SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id
)
SELECT u.name, COALESCE(o.total, 0) AS total
FROM active_users u
LEFT JOIN order_totals o ON o.user_id = u.id;
```
CTEs recursivas usam `WITH RECURSIVE` e exigem condições de término cuidadosas para evitar loops infinitos.

Nomes de tabela e coluna devem usar snake_case ou PascalCase?

A maioria das convenções de banco favorece snake_case (`user_id`, `created_at`) porque todos os principais motores convertem identificadores não-aspeados para minúsculas ou maiúsculas internamente, tornando misturar caixa frágil. PostgreSQL converte para minúsculas; Oracle e DB2 para maiúsculas. Identificadores PascalCase ou camelCase exigem aspas duplas (`"UserId"`) para preservar a caixa, o que é verboso e propenso a erros. snake_case é o padrão de fato nos ecossistemas PostgreSQL, MySQL e SQLite. PascalCase é mais comum no SQL Server (T-SQL), onde o motor preserva a caixa nos metadados. ORMs como Hibernate e Sequelize fornecem conversão automática (camelCase no código, snake_case no DB) via mapeadores de nomes de colunas.

Quais ferramentas formatam SQL automaticamente?

Principais ferramentas em 2025: **sqlfluff** (Python, multi-dialeto, opinionativa, usada pelo dbt) — a mais popular, faz lint e fix; **pg_format** (Perl, foco em PostgreSQL, rápida); **sql-formatter** (JavaScript, multi-dialeto); **sqlfmt** (do Tylerb, baseada em Go, opinionativa como o Black); **Poor SQL** (online); e plugins de IDE para VSCode (SQLTools), DataGrip e SQL Server Management Studio. A adoção do sqlfluff pelo dbt padronizou o estilo SQL na comunidade analítica. A integração com CI é direta: `sqlfluff lint models/` e `sqlfluff fix --force models/` no GitHub Actions ou GitLab CI antes do merge. Configure o dialeto em `.sqlfluff` para corresponder ao seu banco (postgres, snowflake, bigquery, mysql, etc.).

Recursos Principais

• Formatar SQL com indentação personalizável
• Palavras-chave em maiúsculas/minúsculas
• Destaque de sintaxe
• Suporta múltiplos dialetos SQL