Formatador SQL

Formatador SQL - Formatar, Minificar e Analisar em 15 Dialetos

Uma poderosa ferramenta online para formatar, embelezar e minificar SQL com segurança, compatível com 15 dialetos — SQL Padrão, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL (SQL Server), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark SQL, Trino/Presto, Hive e N1QL. Inclui destaque de sintaxe, palavras-chave em maiúsculas, indentação personalizável, minificação ciente de strings e comentários que nunca corrompe seus dados, e uma Verificação de Segurança integrada que detecta instruções UPDATE/DELETE sem cláusula WHERE e comandos destrutivos TRUNCATE/DROP antes de você executá-los. Perfeito para desenvolvedores de bancos de dados, DBAs e engenheiros backend que revisam scripts de migração ou manutenção.

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.

Ele formata BigQuery, Snowflake ou T-SQL especificamente?

Sim. O menu Dialeto suporta 15 gramáticas e cada uma muda como o formatador trata palavras-chave, operadores e aspas. Escolha **bigquery** para identificadores `projeto.dataset.tabela` com crases, sintaxe de arrays/structs e funções STANDARD SQL; **snowflake** para o operador de cast `::`, acesso por caminho semiestruturado `:` e FLATTEN; **tsql** para identificadores `[entre colchetes]` do SQL Server, TOP e `@variáveis`; **postgresql** para placeholders `$1`, casts `::tipo` e strings com dollar-quoting. Também suporta: MySQL, MariaDB, SQLite, Oracle PL/SQL, Redshift, DB2, Spark SQL, Trino/Presto, Hive e N1QL (Couchbase). Se escolher o dialeto errado a saída ainda é válida, mas pode não alinhar a sintaxe específica do motor de forma ideal, então combine o menu com seu banco de dados para o resultado mais limpo.

O Minificar mantém meus dados de string intactos?

Sim. O minificador é baseado em tokenizador: ele percorre a consulta e pula literais entre aspas simples, duplas e crases, bem como comentários `--` e `/* */`, colapsando espaços e removendo comentários APENAS nas regiões de código ao redor. Isso significa que um valor como `'John Doe'` mantém seu espaço duplo, `'50% -- off'` não é truncado no `--`, e `'a/*b*/c'` é preservado literalmente. Minificadores ingênuos anteriores que executam um replace `\s+` global mudam silenciosamente a semântica da consulta — esta ferramenta não. Execute Minificar ou Formatar e o selo de **Verificação de Segurança** acima da saída também informa quantas instruções foram analisadas, para você confirmar que a ferramenta leu seu script como esperava.

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
• Minificação segura que preserva strings e marcadores de comentário entre aspas
• Verificação de Segurança que detecta UPDATE/DELETE sem WHERE e TRUNCATE/DROP
• Contador de instruções para scripts com várias consultas
• Destaque de sintaxe
• Estatísticas em tempo real
• Modo escuro
• 15 dialetos: MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark, Trino/Presto, Hive, N1QL
• 100% no lado do cliente - sem execução de SQL