Formateador y Minificador de SQL

Formateador SQL - Formatear, Minificar y Analizar en 15 Dialectos

Una potente herramienta online para formatear, embellecer y minificar SQL de forma segura, compatible con 15 dialectos — SQL Estándar, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL (SQL Server), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark SQL, Trino/Presto, Hive y N1QL. Incluye resaltado de sintaxis, palabras clave en mayúsculas, sangría personalizable, minificación consciente de cadenas y comentarios que nunca corrompe sus datos, y una Comprobación de Seguridad integrada que detecta sentencias UPDATE/DELETE sin cláusula WHERE y comandos destructivos TRUNCATE/DROP antes de ejecutarlos. Perfecto para desarrolladores de bases de datos, DBAs e ingenieros backend que revisan scripts de migración o mantenimiento.

¿Cuál es el estilo estándar de formato SQL?

No hay un estándar oficial único, pero la convención más adoptada sigue el estilo de Joe Celko (de SQL for Smarties): palabras clave MAYÚSCULAS, identificadores en minúsculas o snake_case, una cláusula por línea (SELECT, FROM, WHERE, etc.), columnas indentadas bajo SELECT y joins alineados bajo FROM. Herramientas modernas como sqlfluff, sql-formatter y pgFormatter implementan variaciones. El estándar SQL ISO/IEC 9075 sólo define sintaxis y semántica, no estilo. La documentación de cada proveedor sugiere guías: el wiki de PostgreSQL tiene una página de estilo y SQL Server T-SQL tiene guías de Microsoft Press. La coherencia dentro del equipo importa más que el estilo específico elegido.

¿Por qué usar MAYÚSCULAS para las palabras clave SQL?

Las palabras clave en mayúsculas (SELECT, FROM, WHERE, JOIN) separan visualmente la sintaxis SQL de los identificadores definidos por el usuario (nombres de tabla y columna), permitiendo escanear consultas de un vistazo. La convención surgió en los mainframes de los años 70 donde las tarjetas perforadas usaban mayúsculas. Los analizadores SQL modernos son insensibles a mayúsculas/minúsculas para palabras clave según ISO 9075, así que `select` funciona idéntico a `SELECT`. Algunos equipos prefieren minúsculas por velocidad de escritura y estética moderna — la documentación de Carbon (IBM) y la API de Stripe usan minúsculas. Herramientas como sqlfluff permiten ambos con `--rules L030`. La elección es puramente estilística; elija una y aplíquela consistentemente.

¿Cómo deben formatearse los JOIN para legibilidad?

Cada JOIN va en su propia línea, con la cláusula ON indentada o en la siguiente línea. El estilo moderno alinea JOINs bajo FROM y agrupa condiciones 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';
```
La sintaxis explícita JOIN (el estándar ANSI SQL-92) es preferible al FROM con comas implícitas porque separa limpiamente las condiciones de join de los filtros y evita productos cartesianos accidentales. Los planes EXPLAIN ANALYZE de PostgreSQL optimizan ambas formas igual, pero la diferencia de legibilidad se acumula en consultas con 5+ tablas.

¿Qué es la minificación SQL y vale la pena?

La minificación SQL elimina espacios, comentarios y saltos de línea innecesarios para reducir el tamaño de la cadena de consulta. Útil al incrustar SQL en código JavaScript/TypeScript que se envía a clientes, en parámetros de URL para herramientas de analítica o en cargas JSON donde cada byte importa. Herramientas como `sql-minifier-cli` y `sqlmin` lo gestionan. Advertencias: el SQL minificado es difícil de depurar y revisar, y la mayoría de servidores de base de datos lo analizan idéntico — no hay ganancia de rendimiento en tiempo de ejecución. Los sistemas de construcción modernos (Vite, Webpack) suelen minificar SQL incrustado automáticamente. Mantenga el SQL fuente formateado para humanos, minifique sólo en compilación para producción.

¿Cómo prevengo la inyección SQL en consultas formateadas?

Use siempre consultas parametrizadas (sentencias preparadas) en lugar de concatenación de cadenas: `SELECT * FROM users WHERE id = $1` con `$1` ligado como parámetro, nunca `SELECT * FROM users WHERE id = ' + userId`. La hoja OWASP de Prevención de Inyección SQL (2023) y CWE-89 listan esto como defensa primaria. Cada SDK moderno lo soporta: `cursor.execute(sql, (id,))` de psycopg, `PreparedStatement.setInt(1, id)` de JDBC, `client.query(text, values)` de Node.js pg. El estilo de formato no tiene impacto en seguridad, pero nunca incluya entrada de usuario directamente en cadenas SQL. Procedimientos almacenados y ORMs añaden capas adicionales de defensa, pero la parametrización adecuada es la base.

¿Qué son las Common Table Expressions (CTE) y cómo las formateo?

Las CTE son subconsultas con nombre definidas con la palabra clave WITH, introducidas en ISO SQL:1999 y soportadas por PostgreSQL, MySQL 8.0+, SQL Server y Oracle. Mejoran la legibilidad al dividir consultas complejas en pasos nombrados y secuenciales. Formatee cada CTE en su propio bloque, separadas por líneas en blanco:
```
WITH usuarios_activos AS (
SELECT id, nombre FROM usuarios WHERE ultimo_login > NOW() - INTERVAL '30 days'
),
totales_pedidos AS (
SELECT usuario_id, SUM(monto) AS total FROM pedidos GROUP BY usuario_id
)
SELECT u.nombre, COALESCE(o.total, 0) AS total
FROM usuarios_activos u
LEFT JOIN totales_pedidos o ON o.usuario_id = u.id;
```
Las CTE recursivas usan `WITH RECURSIVE` y requieren condiciones de terminación cuidadosas para evitar bucles infinitos.

¿Los nombres de tabla y columna deben usar snake_case o PascalCase?

La mayoría de convenciones de bases de datos favorecen snake_case (`user_id`, `created_at`) porque todos los motores principales convierten identificadores no entrecomillados a minúsculas o mayúsculas internamente, haciendo frágil mezclar cajas. PostgreSQL convierte a minúsculas; Oracle y DB2 a mayúsculas. Identificadores PascalCase o camelCase requieren comillas dobles (`"UserId"`) para preservar la caja, lo cual es verboso y propenso a errores. snake_case es el estándar de facto en los ecosistemas PostgreSQL, MySQL y SQLite. PascalCase es más común en SQL Server (T-SQL), donde el motor preserva la caja en metadatos. ORMs como Hibernate y Sequelize hacen conversión automática (camelCase en código, snake_case en BD) vía mapeadores de nombres de columna.

¿Puede formatear BigQuery, Snowflake o T-SQL específicamente?

Sí. El menú Dialecto admite 15 gramáticas y cada una cambia cómo el formateador trata las palabras clave, operadores y entrecomillado. Elija **bigquery** para identificadores `proyecto.dataset.tabla` con comillas invertidas, sintaxis de arrays/structs y funciones STANDARD SQL; **snowflake** para su operador de cast `::`, acceso por ruta semiestructurada `:` y FLATTEN; **tsql** para identificadores `[entre corchetes]` de SQL Server, TOP y `@variables`; **postgresql** para marcadores `$1`, casts `::tipo` y cadenas con dollar-quoting. También admite: MySQL, MariaDB, SQLite, Oracle PL/SQL, Redshift, DB2, Spark SQL, Trino/Presto, Hive y N1QL (Couchbase). Si elige el dialecto equivocado la salida sigue siendo válida pero puede no alinear la sintaxis específica del motor de forma ideal, así que haga coincidir el menú con su base de datos para el resultado más limpio.

¿Minificar conserva intactos mis datos de cadena?

Sí. El minificador se basa en un tokenizador: recorre la consulta y omite literales entre comillas simples, dobles y comillas invertidas, así como comentarios `--` y `/* */`, colapsando espacios y eliminando comentarios SÓLO en las regiones de código circundantes. Esto significa que un valor como `'John Doe'` conserva su doble espacio, `'50% -- off'` no se trunca en el `--`, y `'a/*b*/c'` se preserva literalmente. Los minificadores ingenuos anteriores que ejecutan un reemplazo `\s+` general cambian silenciosamente la semántica de la consulta — esta herramienta no. Ejecute Minificar o Formatear y la insignia de **Comprobación de Seguridad** sobre la salida también le indica cuántas sentencias se analizaron, para confirmar que la herramienta leyó su script como esperaba.

¿Qué herramientas formatean SQL automáticamente?

Herramientas líderes en 2025: **sqlfluff** (Python, multi-dialecto, opinada, usada por dbt) — la más popular, lint y fix; **pg_format** (Perl, enfocada en PostgreSQL, rápida); **sql-formatter** (JavaScript, multi-dialecto); **sqlfmt** (de Tylerb, basada en Go, opinada como Black); **Poor SQL** (en línea); y plugins de IDE para VSCode (SQLTools), DataGrip y SQL Server Management Studio. La adopción de sqlfluff por dbt ha estandarizado el estilo SQL en la comunidad analítica. La integración CI es sencilla: `sqlfluff lint models/` y `sqlfluff fix --force models/` en GitHub Actions o GitLab CI antes de fusionar. Configure el dialecto en `.sqlfluff` para coincidir con su base de datos (postgres, snowflake, bigquery, mysql, etc.).

Características Principales

• Formatear SQL con sangría personalizable
• Opción de palabras clave en mayúsculas para mejor legibilidad
• Minificación segura que preserva cadenas y marcadores de comentario dentro de comillas
• Comprobación de Seguridad que detecta UPDATE/DELETE sin WHERE y TRUNCATE/DROP
• Contador de sentencias para scripts multi-consulta
• Resaltado de sintaxis para palabras clave, funciones, cadenas, números
• Estadísticas en tiempo real
• Soporte para Copiar/Descargar/Cargar
• Modo oscuro
• 15 dialectos: MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark, Trino/Presto, Hive, N1QL
• 100% del lado del cliente - no hay ejecución de SQL
• Compatible con móviles