Formateador SQL

SQL (Structured Query Language) foi criado em 1974 por Donald D. Chamberlin e Raymond F. Boyce nos laboratórios da IBM, inspirado no modelo relacional proposto por Edgar F. Codd em 1970. O objetivo era criar uma linguagem de consulta declarativa: você diz o que quer, não como buscar. Décadas depois, SQL segue sendo a linguagem mais influente da computação que quase todo programador já precisou usar em algum momento — seja em entrevista de emprego, seja num projeto real. A IBM lançou o banco de dados System R com SEQUEL (mais tarde renomeado SQL) em meados dos anos 1970, e a Oracle foi um dos primeiros fornecedores a comercializá-lo. Hoje temos PostgreSQL, MySQL, SQLite, SQL Server e BigQuery, todos com dialetos levemente diferentes, mas o núcleo da linguagem é reconhecível em todos eles.

A legibilidade de SQL é um tema recorrente em equipes de engenharia. Uma query escrita de qualquer jeito — `select id,name from users where active=1 and type='admin' order by name` — faz o mesmo trabalho que uma query bem indentada, com palavras-chave em maiúsculas e cláusulas em linhas separadas. Mas revisar código SQL em pull requests, debugar consultas lentas num explain plan ou simplesmente entender a lógica de uma query que outra pessoa escreveu ficam muito mais fáceis quando o SQL está formatado. A indentação visual de JOINs, condições WHERE e subconsultas reduz erros de leitura e facilita a identificação de problemas de lógica.

Na prática, SQL formatado também importa para ferramentas de versionamento. Quando duas pessoas editam a mesma stored procedure ou migration e uma usa formatação diferente da outra, os diffs ficam poluídos com mudanças cosméticas que mascaram as mudanças reais. Times que adotam uma convenção única de formatação — seja com ferramentas como `sqlfluff`, `pgFormatter` ou formatadores integrados em IDEs — têm revisões de código muito mais produtivas. Para projetos pequenos ou scripts pontuais, um formatador online como este resolve o problema sem configuração alguma.

Esta ferramenta aplica formatação baseada em palavras-chave: quebras de linha antes de SELECT, FROM, WHERE, AND, OR, ORDER BY, GROUP BY, JOIN e variantes, com indentação consistente. Não é um formatador com análise completa de AST como o `sqlfluff` — não valida sintaxe nem sugere otimizações — mas cumpre bem a função de deixar um SQL compacto num formato muito mais legível em segundos. Para dialetos específicos como PostgreSQL com operadores de arrays ou JSON, o resultado pode precisar de ajuste manual nas partes proprietárias.

SQL (Structured Query Language) was created in 1974 by Donald D. Chamberlin and Raymond F. Boyce at IBM Research, inspired by Edgar F. Codd's relational model proposed in 1970. The goal was a declarative query language: you say what you want, not how to get it. Decades later, SQL remains the most influential language in computing that almost every programmer has needed at some point — whether in a job interview or a real project. IBM shipped the System R database with SEQUEL (later renamed SQL) in the mid-1970s, and Oracle was one of the first commercial vendors. Today we have PostgreSQL, MySQL, SQLite, SQL Server, and BigQuery — each with slightly different dialects, but the core language is recognizable across all of them.

SQL readability is a recurring debate in engineering teams. A query written carelessly — `select id,name from users where active=1 and type='admin' order by name` — does the same work as a properly indented one with uppercase keywords and clauses on separate lines. But reviewing SQL in pull requests, debugging slow queries in an explain plan, or simply understanding logic someone else wrote becomes much easier when SQL is formatted. Visual indentation of JOINs, WHERE conditions, and subqueries reduces reading errors and makes logical problems easier to spot.

In practice, formatted SQL also matters for version control. When two people edit the same stored procedure or migration with different formatting preferences, diffs become polluted with cosmetic changes that obscure real ones. Teams that adopt a single formatting convention — using tools like `sqlfluff`, `pgFormatter`, or IDE-integrated formatters — have far more productive code reviews. For small projects or one-off scripts, an online formatter like this one solves the problem without any configuration.

This tool applies keyword-based formatting: line breaks before SELECT, FROM, WHERE, AND, OR, ORDER BY, GROUP BY, JOIN and their variants, with consistent indentation. It is not a full AST-aware formatter like `sqlfluff` — it does not validate syntax or suggest optimizations — but it reliably turns compact SQL into a much more readable form in seconds. For dialect-specific syntax like PostgreSQL array or JSON operators, results in proprietary sections may need manual adjustment.

SQL (Structured Query Language) fue creado en 1974 por Donald D. Chamberlin y Raymond F. Boyce en los laboratorios de IBM, inspirado en el modelo relacional propuesto por Edgar F. Codd en 1970. El objetivo era un lenguaje de consulta declarativo: dices qué quieres, no cómo obtenerlo. Décadas después, SQL sigue siendo el lenguaje más influyente de la informática que casi todo programador ha necesitado en algún momento — sea en una entrevista de trabajo o en un proyecto real. IBM lanzó la base de datos System R con SEQUEL (luego renombrado SQL) a mediados de los años 70, y Oracle fue uno de los primeros proveedores comerciales. Hoy tenemos PostgreSQL, MySQL, SQLite, SQL Server y BigQuery — cada uno con dialectos ligeramente distintos, pero el núcleo del lenguaje es reconocible en todos.

La legibilidad del SQL es un debate recurrente en los equipos de ingeniería. Una query escrita de cualquier manera — `select id,name from users where active=1 and type='admin' order by name` — hace el mismo trabajo que una bien indentada con palabras clave en mayúsculas y cláusulas en líneas separadas. Pero revisar SQL en pull requests, depurar consultas lentas en un explain plan o simplemente entender la lógica de una query que escribió otra persona se vuelve mucho más fácil cuando el SQL está formateado. La indentación visual de JOINs, condiciones WHERE y subconsultas reduce errores de lectura y facilita identificar problemas lógicos.

En la práctica, el SQL formateado también importa para el control de versiones. Cuando dos personas editan el mismo procedimiento almacenado o migración con estilos de formato distintos, los diffs se contaminan con cambios cosméticos que ocultan los cambios reales. Los equipos que adoptan una convención única de formateo — usando herramientas como `sqlfluff`, `pgFormatter` o los formateadores integrados en el IDE — tienen revisiones de código mucho más productivas. Para proyectos pequeños o scripts puntuales, un formateador online como este resuelve el problema sin ninguna configuración.

Esta herramienta aplica formateo basado en palabras clave: saltos de línea antes de SELECT, FROM, WHERE, AND, OR, ORDER BY, GROUP BY, JOIN y sus variantes, con sangría consistente. No es un formateador con análisis completo de AST como `sqlfluff` — no valida sintaxis ni sugiere optimizaciones — pero cumple bien la función de convertir SQL compacto en una forma mucho más legible en segundos. Para sintaxis específica de dialectos como los operadores de arrays o JSON de PostgreSQL, los resultados en partes propietarias pueden necesitar ajuste manual.