T
sql format beautify database developer-tools

Formateador SQL: Embellece y Formatea tus Consultas SQL al Instante

Mejora la legibilidad de tus consultas SQL con nuestro formateador SQL en línea. Formatea, embellece y limpia fácilmente scripts de bases de datos complejos.

2026-04-09 Usar esta herramienta

Introducción

Todo desarrollador que trabaja con bases de datos ha encontrado alguna vez una pared de SQL sin formatear: palabras clave en minúsculas, sin saltos de línea, nombres de tablas pegados a las condiciones JOIN, todo en una sola línea que se extiende interminablemente hacia la derecha. Es casi imposible depurarlo, revisarlo en un pull request o entregárselo a un compañero. El formateo de SQL no es meramente cosmético — es una disciplina profesional que mejora la legibilidad, reduce errores, aplica estándares de equipo y hace que el mantenimiento sea significativamente más fácil.

Ya sea que estés escribiendo un SELECT de cinco líneas o un pipeline analítico de cien líneas con CTEs y funciones de ventana, el formateo consistente es la diferencia entre código que comunica intención y código que la obscurece.

Una Breve Historia de SQL

SQL nació a principios de la década de 1970 en el Laboratorio de Investigación de San José de IBM, donde el modelo relacional de Edgar F. Codd inspiró a Donald D. Chamberlin y Raymond F. Boyce a desarrollar un lenguaje llamado SEQUEL (Structured English Query Language). Más tarde fue renombrado SQL. IBM lo implementó en System R, y Oracle se convirtió en la primera empresa en vender una base de datos SQL comercial en 1979.

El Instituto Nacional Americano de Estándares (ANSI) publicó el primer estándar SQL en 1986, seguido de la ratificación ISO. Las revisiones posteriores — SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011, SQL:2016 — añadieron progresivamente características como disparadores, procedimientos almacenados, consultas recursivas (CTEs), funciones de ventana y soporte JSON.

A pesar del estándar, cada proveedor principal de bases de datos introdujo extensiones propietarias, dando lugar a dialectos: MySQL, PostgreSQL, Microsoft SQL Server (T-SQL), SQLite, Oracle PL/SQL y otros. Estos dialectos comparten un núcleo común pero difieren en la sintaxis para operaciones de cadenas, funciones de fecha, columnas de identidad y más.

Fundamentos de Sintaxis SQL

Antes de formatear, conviene entender los bloques de construcción. Una declaración SELECT estándar sigue este orden lógico:

SELECT   -- columnas a retornar
FROM     -- tablas fuente
JOIN     -- tablas relacionadas
WHERE    -- filtros a nivel de fila
GROUP BY -- agrupación de agregación
HAVING   -- filtros a nivel de agregado
ORDER BY -- orden de clasificación
LIMIT    -- restricción de conteo de filas

Cada cláusula tiene un propósito distinto. WHERE filtra antes de la agregación; HAVING filtra después. GROUP BY colapsa múltiples filas en una por grupo. ORDER BY se aplica al final (antes de LIMIT). Comprender este orden te ayuda a formatear consultas para que cada cláusula comience en su propia línea, haciendo que el flujo lógico sea inmediatamente visible.

Convenciones de Formateo

No existe un estándar universal único, pero las siguientes convenciones son ampliamente adoptadas:

Capitalización de Palabras Clave La mayoría de las guías de estilo recomiendan escribir las palabras clave SQL (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT) en MAYÚSCULAS. Esto proporciona contraste visual entre las palabras clave estructurales y los identificadores definidos por el usuario. Algunos equipos modernos prefieren minúsculas por estética, y herramientas como dbt han popularizado ese estilo. La regla clave: sé consistente.

Indentación Usa 4 espacios (o 2 espacios en estilos compactos) para indentar listas de columnas, cláusulas ON y predicados WHERE. Los tabuladores deben evitarse en bases de código compartidas debido al renderizado inconsistente en diferentes editores.

Saltos de Línea Cada cláusula principal (SELECT, FROM, WHERE, GROUP BY, etc.) debe comenzar en su propia línea. Las listas de columnas en SELECT deben colocarse una por línea, indentadas bajo la palabra clave. Esto facilita agregar, eliminar o comentar columnas individuales.

Posición de la Coma Hay dos corrientes: comas al final (fin de línea) y comas al inicio (inicio de la siguiente línea). Las comas al final son más naturales para la mayoría de los programadores; las comas al inicio facilitan detectar una coma faltante de un vistazo. Elige una y mantenla.

Alias Siempre usa la palabra clave AS al crear alias (u AS usuario, no u usuario). Esto hace que la intención sea explícita y evita ambigüedades en consultas complejas.

Ejemplo de Formateo Antes y Después

-- ANTES (sin formatear)
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 and u.active=1 order by o.total desc limit 10

-- DESPUÉS (formateado)
SELECT
    u.id,
    u.name,
    o.total
FROM
    users u
    INNER JOIN orders o ON u.id = o.user_id
WHERE
    o.total > 100
    AND u.active = 1
ORDER BY
    o.total DESC
LIMIT 10

La versión formateada hace que la relación entre tablas, las condiciones de filtro y el orden de clasificación sean inmediatamente escaneables.

Comparación de Dialectos SQL

Aunque SQL está estandarizado, los dialectos difieren en aspectos importantes:

Característica MySQL PostgreSQL SQL Server SQLite
Concatenación de cadenas CONCAT() || o CONCAT() + o CONCAT() ||
Auto-incremento AUTO_INCREMENT SERIAL / IDENTITY IDENTITY AUTOINCREMENT
Limitar filas LIMIT n LIMIT n TOP n LIMIT n
Funciones de fecha DATE(), NOW() CURRENT_DATE, NOW() GETDATE() DATE()
Sensibilidad a mayúsculas Por defecto: insensible Por defecto: sensible Por defecto: insensible Configurable

Entender estas diferencias es crítico al portar consultas entre bases de datos. Un formateador que conoce el dialecto objetivo puede producir salidas sintácticamente válidas incluso para construcciones específicas del dialecto.

Guías de Estilo SQL

Dos guías de estilo ampliamente referenciadas ayudan a los equipos a establecer consenso:

Guía de Estilo SQL de Simon Holywell (sqlstyle.guide) Esta guía enfatiza la alineación de palabras raíz, el uso de ríos de espacio en blanco para separar visualmente las cláusulas, comas al inicio e identificadores en snake_case. Es opinativa pero exhaustiva y ampliamente utilizada en equipos de ingeniería de datos.

Guía de Estilo SQL de Google La guía de estilo interna de Google (parcialmente pública a través de la documentación de BigQuery) favorece las comas al final, indentación de 4 espacios, palabras clave en MAYÚSCULAS y el ajuste de listas IN largas. Se alinea bien con los estándares de codificación Java con los que están familiarizados muchos ingenieros de Google.

La mayoría de los equipos crean una guía de estilo interna ligera derivada de una de estas y la aplican mediante formateo automático en pipelines CI.

Cómo Funcionan los Formateadores SQL

Un formateador SQL es, en esencia, un front-end de compilador especializado. El proceso típicamente involucra tres etapas:

1. Análisis Léxico (Tokenización) La cadena SQL sin procesar se descompone en un flujo plano de tokens: palabras clave (SELECT, FROM), identificadores (users, u), operadores (=, >), literales ('completed', 100), puntuación (,, ;) y espacios en blanco/comentarios. El analizador léxico no entiende la estructura — solo clasifica caracteres.

2. Análisis Sintáctico (Parsing) El flujo de tokens se introduce en un analizador que construye un Árbol de Sintaxis Abstracta (AST). Cada nodo en el AST representa una construcción lógica: un nodo SelectStatement contiene un nodo ColumnList, un nodo FromClause, un nodo WhereClause, etc. El analizador aplica reglas gramaticales y detecta errores de sintaxis.

3. Re-emisión (Pretty Printing) El formateador recorre el AST y emite texto SQL según las reglas de formateo: saltos de línea después de las palabras clave de cláusula, indentación para nodos hijos, espacios alrededor de operadores, transformaciones de mayúsculas/minúsculas en palabras clave. Dado que la salida se deriva del AST en lugar de manipulación de cadenas, el significado semántico de la consulta se preserva perfectamente.

Algunos formateadores más simples omiten la construcción completa del AST y aplican transformaciones basadas en reglas directamente en el flujo de tokens. Esto es más rápido pero menos preciso para estructuras anidadas complejas.

Patrones SQL Comunes con Ejemplos

JOIN de Múltiples Tablas

SELECT
    c.name AS customer_name,
    p.name AS product_name,
    oi.quantity,
    oi.unit_price
FROM
    customers c
    INNER JOIN orders o ON c.id = o.customer_id
    INNER JOIN order_items oi ON o.id = oi.order_id
    INNER JOIN products p ON oi.product_id = p.id
WHERE
    o.status = 'shipped'
    AND o.created_at >= '2024-01-01'
ORDER BY
    c.name,
    o.created_at DESC;

Subconsulta

SELECT
    department,
    AVG(salary) AS avg_salary
FROM employees
WHERE salary > (
    SELECT AVG(salary)
    FROM employees
)
GROUP BY department
ORDER BY avg_salary DESC;

CTE (Expresión de Tabla Común)

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', created_at) AS month,
        SUM(amount) AS revenue
    FROM orders
    WHERE status = 'completed'
    GROUP BY 1
),
ranked_months AS (
    SELECT
        month,
        revenue,
        RANK() OVER (ORDER BY revenue DESC) AS rank
    FROM monthly_revenue
)
SELECT *
FROM ranked_months
WHERE rank <= 3;

Los CTEs mejoran la legibilidad al descomponer consultas complejas en bloques de construcción con nombre y reutilizables. Son especialmente valiosos en SQL analítico donde las agregaciones intermedias alimentan cálculos posteriores.

Funciones de Ventana

SELECT
    employee_id,
    department,
    salary,
    AVG(salary) OVER (PARTITION BY department) AS dept_avg,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank
FROM employees;

Las funciones de ventana (ROW_NUMBER, RANK, LAG, LEAD, SUM, AVG con OVER) son de las más poderosas en SQL. El formateo adecuado — cada cláusula OVER en la misma línea que su función — es esencial para la legibilidad.

Agregación con HAVING

SELECT
    category,
    COUNT(*) AS total_products,
    AVG(price) AS avg_price,
    MAX(price) AS max_price
FROM products
WHERE active = 1
GROUP BY category
HAVING COUNT(*) > 10
ORDER BY avg_price DESC;

Integración con IDEs y Herramientas

VS Code El paquete npm sql-formatter potencia varias extensiones de VS Code. Configura el formateo al guardar en settings.json:

"[sql]": { "editor.defaultFormatter": "mtxr.sqltools" }

JetBrains DataGrip DataGrip tiene formateo SQL incorporado bajo Código → Reformatear Código (Ctrl+Alt+L). Las opciones de estilo son configurables por dialecto de fuente de datos en Configuración → Editor → Estilo de Código → SQL.

DBeaver DBeaver soporta el formateo SQL a través de Editor SQL → Formatear SQL y permite configuración personalizada del formateador en Preferencias → Editores → Editor SQL → Formateo.

Línea de Comandos El paquete npm sql-formatter puede usarse como herramienta CLI:

npx sql-formatter --language postgresql --indent 4 query.sql

Mejores Prácticas

  1. Formatea pronto, formatea frecuentemente. Ejecuta el formateador antes de cada commit, no solo antes de la revisión de código.
  2. Acuerda una guía de estilo primero. Ningún formateador puede sustituir el consenso del equipo sobre convenciones.
  3. Usa alias de forma consistente. Los alias cortos (1-2 letras) son adecuados para consultas simples; los alias descriptivos mejoran la legibilidad en las complejas.
  4. Nombra los CTEs descriptivamente. monthly_revenue es mejor que cte1 o tmp.
  5. Comenta la lógica compleja. Una consulta bien formateada con comentarios en línea que explican reglas de negocio no obvias es mucho más mantenible que SQL inteligente pero silencioso.
  6. Aplica linting SQL en CI. Herramientas como sqlfluff pueden aplicar reglas de formateo automáticamente en pipelines de pull requests.
  7. Mantén CASE WHEN legible. Divide cadenas largas de CASE WHEN en múltiples líneas, una rama por línea.
  8. Califica todas las referencias de columnas. En consultas de múltiples tablas, siempre prefija los nombres de columnas con el alias de tabla (u.id y no solo id).

Preguntas Frecuentes

¿El formateo cambia el comportamiento de mi consulta? No. Un formateador solo cambia espacios en blanco, saltos de línea y capitalización de palabras clave. La estructura lógica y el plan de ejecución permanecen idénticos.

¿Puede un formateador corregir errores de sintaxis? No. Los formateadores requieren SQL sintácticamente válido (o casi válido) para analizar correctamente. Usa un linter como sqlfluff para detectar y explicar errores.

¿Qué estilo de capitalización de palabras clave debo usar? Las MAYÚSCULAS para las palabras clave es la convención más tradicional y ampliamente recomendada. Sin embargo, las minúsculas son cada vez más populares en dbt y herramientas de datos modernas. Elige una para tu equipo y aplícala automáticamente.

¿Soporta procedimientos almacenados y bloques PL/SQL? El soporte varía. La mayoría de los formateadores manejan bien DML (SELECT, INSERT, UPDATE, DELETE). Las extensiones procedurales requieren analizadores conscientes del dialecto y varían en calidad de soporte.

¿Están seguros mis datos SQL al usar formateadores en línea? Un buen formateador en línea procesa todo del lado del cliente en el navegador usando JavaScript. Tu consulta nunca abandona tu máquina. Siempre verifica esto en la política de privacidad de la herramienta antes de pegar información sensible de esquema.

¿Cuál es la diferencia entre un formateador y un linter? Un formateador transforma la presentación del SQL sin cambiar su significado. Un linter (sqlfluff, SQLCheck) analiza el SQL en busca de violaciones de estilo, antipatrones y errores potenciales, reportando problemas en lugar de corregirlos automáticamente.

Volver al blog Formateador SQL →