Formateador SQL gratuito

SQL, breve historia del lenguaje que se está formateando

SQL (Structured Query Language) fue desarrollado en IBM por Donald D. Chamberlin y Raymond F. Boyce a comienzos de los años 1970, originalmente como SEQUEL («Structured English Query Language»), renombrado a SQL tras un conflicto de marca. El lenguaje fue comercializado por primera vez por el predecesor de Oracle (Relational Software, Inc.) en 1979, Oracle V2 fue la primera base de datos SQL comercial, adelantándose al propio DB2 de IBM en el mercado. El primer estándar ANSI, ANSI SQL-86, se publicó en 1986; la revisión mucho más sustancial SQL-92 (el «gran» estándar SQL, ISO/IEC 9075:1992) definió la mayor parte de la sintaxis que los usuarios modernos reconocen, sintaxis JOIN, operaciones de conjunto, subconsultas, transacciones. Las revisiones siguientes añadieron características objeto-relacionales (SQL:1999), soporte XML (SQL:2003), funciones de ventana y CTE (SQL:2003 y 2008), consultas temporales (SQL:2011), soporte JSON (SQL:2016, ampliado en SQL:2023). Cada gran fabricante de bases de datos implementa su propio dialecto, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL analítico compatible con PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: todos compartiendo el núcleo SQL-92 pero divergiendo en funciones, extensiones de sintaxis y listas de palabras reservadas. Un buen formateador respeta el dialecto que está formateando porque el mismo identificador podría ser una palabra clave en un dialecto y un nombre de columna legal en otro.

Las convenciones que hacen legible el SQL

Varias convenciones se han vuelto estándar en las guías de estilo SQL, la de Mozilla, la muy citada SQL Style Guide de Simon Holywell, las convenciones del equipo de datos de GitLab, el estilo recomendado por dbt. Palabras clave en MAYÚSCULAS (SELECT, FROM, WHERE, JOIN) frente a identificadores (nombres de tablas y columnas) en minúsculas o snake_case es la convención dominante. Algunas guías de estilo defienden lo opuesto (las palabras clave en minúsculas son más fáciles de teclear y leer), y la documentación oficial de PostgreSQL usa palabras clave en minúsculas en todo su contenido, pero las MAYÚSCULAS se imponen en la mayoría de las bases de código profesionales porque hacen visible la estructura del lenguaje de un vistazo. Cada cláusula importante en su propia línea: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, cada una comienza una nueva línea al mismo nivel de indentación. Condiciones JOIN indentadas bajo ON: la palabra clave JOIN en su propia línea, la palabra clave ON en la siguiente línea indentada un nivel. Coma al inicio o al final en listas de columnas es un argumento estilístico de larga data; coma al inicio (cada línea de columna empieza con la coma) produce diffs más limpios al añadir/eliminar columnas y protege contra el error de sintaxis de coma final, pero resulta visualmente inusual para muchos. Coma al final es más común en código de producción. Indentación de subconsultas: consultas anidadas indentadas un nivel más profundo que su padre. Cláusulas CTE (WITH): cada CTE nombrada en su propia línea, el cuerpo indentado bajo el AS, la consulta principal abajo alineada a la izquierda.

Cuándo recurrirás a un formateador SQL

• Leer consultas registradas por un ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, todos generan SQL programáticamente y lo emiten como una sola línea densa en tus logs de aplicación. Para depurar «¿por qué esta consulta es lenta?», pega el SQL registrado en el formateador y lee lo que el ORM produjo realmente. El resultado a menudo es revelador («ah, eso es un CROSS JOIN donde esperaba un INNER»).
• Revisión de código en PRs de base de datos. Una migración SQL o un cambio de procedimiento almacenado es mucho más fácil de revisar cuando está formateado de forma consistente. Pasa el archivo por el formateador antes de hacer commit para que el diff sea estructural, no ruido de espacios.
• Leer planes EXPLAIN junto con la consulta. Al ajustar una consulta lenta, lees la salida EXPLAIN, luego releees la consulta para encontrar la referencia de tabla en la parte superior del plan. Una consulta formateada hace la referencia cruzada instantánea.
• Pegar SQL en tickets, docs, Slack. Una consulta formateada se lee con claridad; una consulta minificada de una sola línea es ilegible en cualquier contexto estrecho. Formatea antes de compartir.
• Reformateo de consultas legacy con palabras clave en mayúsculas/minúsculas mezcladas. Una base de código de 15 años donde SELECT a veces se escribía Select, a veces select, a veces SELECT se lee mejor después de que el formateador normalice todo a una sola convención.
• Limpiar consultas exportadas desde herramientas BI. Looker, Mode, Metabase, Tableau y herramientas similares te permiten copiar el SQL subyacente pero lo emiten en cualquier formato ad hoc que generen. Formatea antes de leer.

El ecosistema de formateadores SQL

Para flujos de trabajo en línea de comandos e integrados en el editor, existen varias opciones maduras. sql-formatter (paquete npm, originalmente de Andriy Isayev, ahora mantenido por un equipo comunitario) es el formateador SQL dominante del ecosistema JavaScript, soporta MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB y varios otros dialectos. pg_format (Gilles Darold) es el formateador canónico específico para PostgreSQL, escrito en Perl y empaquetado con el popular servicio web pgFormatter. Poor Man's T-SQL Formatter (Tao Klerks, 2011) apunta específicamente al dialecto T-SQL de Microsoft SQL Server. sqlparse (Andi Albrecht) es la biblioteca Python estándar, usada por Django para análisis de consultas y por incontables scripts de ingeniería de datos. SQLFluff es el linter-y-formateador moderno que se integra con proyectos dbt y flujos de trabajo analíticos. DataGrip de JetBrains y el plugin SQL para IntelliJ IDEA incluyen un formateador sofisticado consciente del dialecto; SQLTools de VS Code y varias otras extensiones envuelven la biblioteca npm sql-formatter. Para proyectos con un pipeline de build, el patrón moderno es «formatear al guardar en el editor + un check de CI que falla el build si los archivos SQL están mal formateados», el mismo modelo que Prettier para JavaScript o Black para Python.

Diferencias de dialecto que importan para el formateo

La mayoría de los formateadores SQL funcionan a través de los dialectos con ajustes menores, pero un puñado de diferencias requiere que el formateador sepa qué dialecto está leyendo. Identificadores entrecomillados: SQL estándar usa comillas dobles ("order"); MySQL usa backticks (`order`) por defecto y solo respeta las comillas dobles en modo ANSI; SQL Server usa corchetes ([order]). Concatenación de cadenas: SQL estándar usa ||; MySQL usa CONCAT() o el raro || en modo ANSI; SQL Server usa +. Paginación: MySQL/PostgreSQL/SQLite usan LIMIT/OFFSET; SQL Server usa TOP u OFFSET FETCH; Oracle usa FETCH o ROWNUM. Auto-incremento: AUTO_INCREMENT en MySQL, SERIAL o IDENTITY en PostgreSQL, IDENTITY en SQL Server, AUTOINCREMENT en SQLite. Las listas de palabras reservadas divergen, una columna llamada rank necesita comillas en PostgreSQL (donde RANK es una palabra clave de función de ventana) pero está bien como identificador en MySQL. Un formateador que no conoce el dialecto puede romper consultas válidas añadiendo entrecomillado inadecuado. La salida «Format SQL» de un formateador genérico suele ser correcta para la forma estándar SELECT/INSERT/UPDATE/DELETE; para sintaxis específica del fabricante (funciones de ventana, hints, funciones de sistema), revisa la salida contra la documentación de tu dialecto.

Privacidad: por qué el solo-navegador importa especialmente para SQL

Las consultas SQL son algunos de los textos más sensibles en cualquier organización: exponen nombres de tablas internas (que revelan la taxonomía de producto), nombres de columnas (que revelan el modelo de datos), valores de filtro (que pueden incluir IDs de usuario reales, direcciones de email, IDs de negocio), credenciales literales embebidas en patrones más antiguos, y la estructura de análisis que la empresa puede considerar propietaria. Los formateadores SQL del lado del servidor toman una copia de cada consulta en sus logs. Este formateador se ejecuta enteramente en tu navegador a través de JavaScript, verifica en la pestaña Red de DevTools mientras haces clic en Format (no se dispara ninguna petición), o pon la página sin conexión (modo avión) tras cargarla y el formateador sigue funcionando. Seguro para consultas de producción que contengan nombres de tablas reales y valores de filtro PII, SQL analítico interno, pipelines ETL, o cualquier consulta que no quisieras ver copiada en el disco duro de un extraño.

Preguntas frecuentes

¿Puede el formateador poner las palabras clave SQL en mayúsculas automáticamente?

Sí, el conmutador Palabras clave controla el caso. MAYÚSCULAS es la convención profesional dominante porque hace visible la estructura del lenguaje de un vistazo (SELECT, FROM, WHERE destacan de los identificadores); minúsculas es preferida por algunas guías de estilo (la documentación oficial de PostgreSQL usa minúsculas en todo) con el argumento de que es más fácil de leer y más rápido de teclear. Cualquiera funciona siempre que tu equipo elija una y la use de forma consistente. La capitalización no tiene efecto sobre el comportamiento de la consulta, las palabras clave SQL son insensibles al caso en el momento del parsing.

¿Cómo personalizo la indentación?

El menú Indentación soporta 2 espacios (la convención web moderna dominante), 4 espacios (todavía comunes en tiendas Java y .NET más antiguas), o caracteres de tabulación. 2 espacios tiende a ganar en bases de código más nuevas y para SQL en particular porque el anidamiento profundo de subconsultas cabe más cómodamente dentro de un límite de línea de 100 caracteres. Adáptate a la convención que tu equipo ya use; la consistencia importa más que la elección específica.

¿Funciona con consultas grandes?

Sí, como el formateo se ejecuta en tu navegador, el techo práctico es la memoria disponible de tu dispositivo. Cientos de líneas de SQL se formatean en mucho menos de un segundo; las consultas de varios miles de líneas (típicas en ETL de almacén de datos) funcionan pero pueden congelar brevemente la pestaña mientras el parser recorre la estructura. Para reformateo en lote de un repositorio SQL completo, las herramientas de línea de comandos (sql-formatter vía npm, pg_format para PostgreSQL, SQLFluff para proyectos dbt) son más apropiadas.

¿Reconocerá el formateador mi dialecto SQL específico?

Maneja correctamente las formas comunes SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/subconsulta a través de MySQL, PostgreSQL, SQLite, T-SQL y SQL ANSI estándar. La sintaxis específica del fabricante, cláusulas de funciones de ventana, sentencias MERGE, hints específicos del dialecto, funciones de sistema, operadores de array al estilo PostgreSQL, métodos XML T-SQL, puede formatearse de forma imperfecta. Revisa la salida puntualmente y ejecuta la consulta formateada contra tu base de datos para confirmar que se parsea correctamente antes de hacer commit.

¿Se sube mi SQL?

No. El formateo se ejecuta enteramente en tu navegador, las consultas pegadas nunca salen de tu dispositivo. Verifica en la pestaña Red de DevTools mientras haces clic en Format (no se dispara ninguna petición), o pon la página sin conexión (modo avión) tras cargarla. Seguro para consultas de producción que contengan nombres de tablas sensibles, valores de filtro PII, o cualquier SQL cubierto por NDA o regulación de cumplimiento.

Herramientas relacionadas