Formatador SQL gratuito

SQL, uma breve história da linguagem que está a ser formatada

SQL (Structured Query Language) foi desenvolvida na IBM por Donald D. Chamberlin e Raymond F. Boyce no início dos anos 1970, originalmente como SEQUEL («Structured English Query Language»), renomeada para SQL após um conflito de marca. A linguagem foi comercializada pela primeira vez pelo predecessor da Oracle (Relational Software, Inc.) em 1979, Oracle V2 foi a primeira base de dados SQL comercial, antecipando-se ao próprio DB2 da IBM no mercado. A primeira norma ANSI, ANSI SQL-86, foi publicada em 1986; a revisão muito mais substancial SQL-92 (a «grande» norma SQL, ISO/IEC 9075:1992) definiu a maior parte da sintaxe que os utilizadores modernos reconhecem, sintaxe JOIN, operações de conjunto, subconsultas, transacções. Revisões subsequentes acrescentaram funcionalidades objecto-relacionais (SQL:1999), suporte XML (SQL:2003), funções de janela e CTEs (SQL:2003 e 2008), consultas temporais (SQL:2011), suporte JSON (SQL:2016, expandido em SQL:2023). Cada grande fornecedor de bases de dados implementa o seu próprio dialecto, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL analítico compatível com PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: todos partilhando o núcleo SQL-92 mas divergindo em funções, extensões de sintaxe e listas de palavras reservadas. Um bom formatador respeita o dialecto que está a formatar porque o mesmo identificador pode ser uma palavra-chave num dialecto e um nome de coluna legal noutro.

Convenções que tornam o SQL legível

Várias convenções tornaram-se padrão nos guias de estilo SQL, o da Mozilla, o muito citado SQL Style Guide de Simon Holywell, as convenções da equipa de dados da GitLab, o estilo recomendado por dbt. Palavras-chave em MAIÚSCULAS (SELECT, FROM, WHERE, JOIN) versus identificadores (nomes de tabelas e colunas) em minúsculas ou snake_case é a convenção dominante. Alguns guias de estilo defendem o oposto (palavras-chave em minúsculas são mais fáceis de digitar e ler), e a documentação oficial do PostgreSQL usa palavras-chave em minúsculas em todo o seu conteúdo, mas as MAIÚSCULAS impõem-se na maioria das bases de código profissionais porque tornam a estrutura da linguagem visível num relance. Cada cláusula importante na sua própria linha: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, cada uma começa uma nova linha ao mesmo nível de indentação. Condições JOIN indentadas sob ON: a palavra-chave JOIN na sua própria linha, a palavra-chave ON na linha seguinte indentada um nível. Vírgula no início ou no fim em listas de colunas é um argumento estilístico de longa data; vírgula no início (cada linha de coluna começa com a vírgula) produz diffs mais limpos ao adicionar/remover colunas e protege contra o erro de sintaxe de vírgula final, mas parece visualmente inusual a muitos. Vírgula no fim é mais comum em código de produção. Indentação de subconsultas: consultas aninhadas indentadas um nível mais fundo do que o seu pai. Cláusulas CTE (WITH): cada CTE nomeada na sua própria linha, o corpo indentado sob o AS, a consulta principal em baixo alinhada à esquerda.

Quando vai recorrer a um formatador SQL

• Ler consultas registadas por um ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, todos geram SQL programaticamente e emitem-no como uma única linha densa nos seus logs de aplicação. Para depurar «porque é que esta consulta é lenta», cole o SQL registado no formatador e leia o que o ORM realmente produziu. O resultado é frequentemente esclarecedor («ah, isso é um CROSS JOIN onde eu esperava um INNER»).
• Revisão de código em PRs de base de dados. Uma migração SQL ou uma alteração de procedimento armazenado é muito mais fácil de rever quando está formatada de modo consistente. Passe o ficheiro pelo formatador antes de fazer commit para que o diff seja estrutural, não ruído de espaçamento.
• Ler planos EXPLAIN ao lado da consulta. Ao afinar uma consulta lenta, lê a saída EXPLAIN, depois relê a consulta para encontrar a referência de tabela no topo do plano. Uma consulta formatada torna o cruzamento instantâneo.
• Colar SQL em tickets, docs, Slack. Uma consulta formatada lê-se claramente; uma consulta minificada de uma única linha é ilegível em qualquer contexto estreito. Formate antes de partilhar.
• Reformatar consultas legacy com palavras-chave em maiúsculas/minúsculas misturadas. Uma base de código de 15 anos onde SELECT por vezes era escrito Select, por vezes select, por vezes SELECT lê-se melhor após o formatador normalizar tudo para uma única convenção.
• Limpar consultas exportadas de ferramentas BI. Looker, Mode, Metabase, Tableau e ferramentas similares deixam-no copiar o SQL subjacente mas emitem-no num formato ad hoc qualquer que gerem. Formate antes de ler.

O ecossistema de formatadores SQL

Para fluxos de trabalho em linha de comandos e integrados ao editor, existem várias opções maduras. sql-formatter (pacote npm, originalmente de Andriy Isayev, agora mantido por uma equipa comunitária) é o formatador SQL dominante do ecossistema JavaScript, suporta MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB e vários outros dialectos. pg_format (Gilles Darold) é o formatador canónico específico do PostgreSQL, escrito em Perl e empacotado com o popular serviço web pgFormatter. Poor Man's T-SQL Formatter (Tao Klerks, 2011) tem como alvo especificamente o dialecto T-SQL do Microsoft SQL Server. sqlparse (Andi Albrecht) é a biblioteca Python padrão, usada pelo Django para análise de consultas e por incontáveis scripts de engenharia de dados. SQLFluff é o linter-e-formatador moderno que se integra a projectos dbt e fluxos de trabalho analíticos. DataGrip da JetBrains e o plugin SQL para IntelliJ IDEA incluem um formatador sofisticado consciente do dialecto; SQLTools do VS Code e várias outras extensões envolvem a biblioteca npm sql-formatter. Para projectos com um pipeline de build, o padrão moderno é «formatar ao gravar no editor + um check de CI que falha o build se os ficheiros SQL estiverem mal formatados», o mesmo modelo do Prettier para JavaScript ou do Black para Python.

Diferenças de dialecto que importam para a formatação

A maioria dos formatadores SQL funciona através dos dialectos com pequenos ajustes, mas um punhado de diferenças exige que o formatador saiba que dialecto está a ler. Identificadores entre aspas: SQL standard usa aspas duplas ("order"); MySQL usa por defeito acentos graves (`order`) e só respeita aspas duplas em modo ANSI; SQL Server usa parênteses rectos ([order]). Concatenação de strings: SQL standard usa ||; MySQL usa CONCAT() ou o raro || em modo ANSI; SQL Server usa +. Paginação: MySQL/PostgreSQL/SQLite usam LIMIT/OFFSET; SQL Server usa TOP ou OFFSET FETCH; Oracle usa FETCH ou ROWNUM. Auto-incremento: AUTO_INCREMENT em MySQL, SERIAL ou IDENTITY em PostgreSQL, IDENTITY em SQL Server, AUTOINCREMENT em SQLite. As listas de palavras reservadas divergem, uma coluna chamada rank precisa de aspas em PostgreSQL (onde RANK é uma palavra-chave de função de janela) mas é boa como identificador em MySQL. Um formatador que não conhece o dialecto pode quebrar consultas válidas adicionando aspas inadequadas. A saída «Format SQL» de um formatador genérico costuma estar correcta para a forma standard SELECT/INSERT/UPDATE/DELETE; para sintaxe específica do fornecedor (funções de janela, hints, funções de sistema), verifique a saída pontualmente contra a documentação do seu dialecto.

Privacidade: por que o apenas-no-navegador importa especialmente para SQL

As consultas SQL estão entre os textos mais sensíveis em qualquer organização: expõem nomes de tabelas internas (que revelam a taxonomia do produto), nomes de colunas (que revelam o modelo de dados), valores de filtro (que podem incluir IDs reais de utilizador, endereços de e-mail, IDs de negócio), credenciais literais embutidas em padrões mais antigos, e a estrutura de análises que a empresa pode considerar proprietárias. Os formatadores SQL do lado do servidor levam uma cópia de cada consulta para os seus logs. Este formatador corre inteiramente no seu navegador através de JavaScript, verifique no separador Rede das DevTools enquanto clica em Format (não dispara nenhum pedido), ou ponha a página offline (modo de avião) após o carregamento e o formatador continua a funcionar. Seguro para consultas de produção contendo nomes reais de tabelas e valores de filtro PII, SQL analítico interno, pipelines ETL, ou qualquer consulta que não queira ver copiada para o disco rígido de um estranho.

Perguntas frequentes

O formatador pode pôr automaticamente as palavras-chave SQL em maiúsculas?

Sim, o interruptor Palavras-chave controla a capitalização. MAIÚSCULAS é a convenção profissional dominante porque torna a estrutura da linguagem visível num relance (SELECT, FROM, WHERE destacam-se dos identificadores); minúsculas é preferida por alguns guias de estilo (a documentação oficial do PostgreSQL usa minúsculas em tudo) com o argumento de que é mais fácil de ler e mais rápido de digitar. Qualquer uma funciona desde que a sua equipa escolha uma e a use de forma consistente. A capitalização não tem efeito no comportamento da consulta, as palavras-chave SQL são insensíveis à capitalização no momento do parsing.

Como personalizo a indentação?

O menu Indentação suporta 2 espaços (a convenção web moderna dominante), 4 espaços (ainda comuns em lojas Java e .NET mais antigas), ou caracteres de tabulação. 2 espaços tendem a ganhar nas bases de código mais recentes e para SQL em particular porque o aninhamento profundo de subconsultas cabe mais confortavelmente dentro de um limite de linha de 100 caracteres. Adapte-se à convenção que a sua equipa já usa; a consistência importa mais do que a escolha específica.

Funciona com consultas grandes?

Sim, como a formatação corre no seu navegador, o tecto prático é a memória disponível do seu dispositivo. Centenas de linhas de SQL formatam-se em muito menos de um segundo; consultas com vários milhares de linhas (típicas em ETL de armazém de dados) funcionam mas podem congelar brevemente o separador enquanto o parser percorre a estrutura. Para reformatação em lote de um repositório SQL completo, ferramentas de linha de comandos (sql-formatter via npm, pg_format para PostgreSQL, SQLFluff para projectos dbt) são mais apropriadas.

O formatador reconhecerá o meu dialecto SQL específico?

Lida correctamente com as formas comuns SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/subconsulta através de MySQL, PostgreSQL, SQLite, T-SQL e SQL ANSI standard. Sintaxe específica do fornecedor, cláusulas de funções de janela, sentenças MERGE, hints específicos do dialecto, funções de sistema, operadores de array no estilo PostgreSQL, métodos XML T-SQL, pode ser formatada de forma imperfeita. Verifique a saída pontualmente e execute a consulta formatada na sua base de dados para confirmar que faz parsing correctamente antes de fazer commit.

O meu SQL é carregado para servidor?

Não. A formatação corre inteiramente no seu navegador, as consultas coladas nunca saem do seu dispositivo. Verifique no separador Rede das DevTools enquanto clica em Format (não dispara nenhum pedido), ou ponha a página offline (modo de avião) após o carregamento. Seguro para consultas de produção contendo nomes de tabelas sensíveis, valores de filtro PII, ou qualquer SQL coberto por NDA ou regulamentação de conformidade.

Ferramentas relacionadas