Formateador y embellecedor de SQL

El Formateador y embellecedor de SQL es una herramienta gratuita que recibe código SQL y devuelve una versión más legible y con un formato uniforme.

¿Qué cambia al dar formato al SQL?

Dar formato al SQL modifica la presentación de una consulta para que sus cláusulas, expresiones y estructuras anidadas sean más fáciles de seguir. Normalmente, añade saltos de línea y sangrías en elementos como las listas SELECT, las cláusulas JOIN, las condiciones WHERE, las subconsultas y las expresiones CASE.

El formato no debería alterar el resultado previsto de la consulta. Sin embargo, los dialectos SQL varían y el formato por sí solo no permite demostrar que una sentencia conserva su significado. Revisa el SQL generado antes de ejecutarlo con datos de producción, sobre todo si utiliza operadores específicos de un proveedor, extensiones procedimentales o reglas de comillas poco habituales.

Un formateador resulta útil para leer consultas de terceros, revisar SQL generado, depurar una sentencia larga o preparar código para una solicitud de incorporación de cambios. Un formato uniforme también facilita la comparación de modificaciones, ya que reduce las diferencias de espaciado que no guardan relación con el contenido.

¿Cómo uso el formateador de SQL?

Pega o escribe la sentencia en el campo SQL y envíala para obtener la versión formateada en SQL embellecido. La entrada se envía al servidor mediante HTTPS para procesarla y no se almacena.

1. Copia la sentencia completa, incluidas las expresiones de tabla comunes que necesites conservar, y comprueba en el resultado los comentarios y cualquier punto y coma final.
2. Introdúcela en el campo SQL. Siempre que sea posible, evita dar formato a fragmentos aislados.
3. Revisa el resultado en SQL embellecido y presta especial atención a las expresiones anidadas y a la sintaxis propia del dialecto.
4. Ejecuta la sentencia formateada en un entorno adecuado de desarrollo o preproducción antes de implementarla.

Si trabajas con bases de datos sensibles, consulta la política de tu organización antes de enviar el texto de una consulta a cualquier utilidad alojada en un servidor. Elimina contraseñas, tokens de acceso, datos personales y valores literales confidenciales si no son necesarios para entender la consulta.

¿Cómo interpreto el SQL formateado?

Lee el resultado siguiendo la sangría y los límites entre cláusulas. No des por hecho que la sentencia es válida solo porque ahora esté mejor organizada. Las cláusulas SELECT, FROM, WHERE, GROUP BY y ORDER BY de nivel superior suelen distinguirse con más facilidad cuando cada parte lógica ocupa su propia línea o nivel de sangría.

• Las subconsultas con sangría muestran dónde utiliza una sentencia externa el resultado de una consulta interna.
• Las condiciones alineadas facilitan la revisión de la precedencia de AND y OR. No obstante, AND tiene prioridad sobre OR de forma predeterminada y los paréntesis siguen determinando la agrupación lógica.
• Las cláusulas JOIN separadas ayudan a identificar qué condición ON corresponde a cada tabla.
• Las listas SELECT expandidas permiten detectar más fácilmente comas ausentes, columnas duplicadas y alias ambiguos.
• Las ramas CASE visibles ayudan a relacionar las palabras clave WHEN, THEN, ELSE y END.

Las cadenas entre comillas, los números, los signos de puntuación y los comentarios tienen significado en SQL. Revísalos en lugar de asumir que son meros elementos de presentación. Los caracteres acentuados o no latinos pueden ser válidos dentro de literales de cadena e identificadores entre comillas, según la base de datos y su codificación de caracteres.

Ejemplos sencillos de formato

Observa esta entrada compacta.

Entrada: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Una versión legible y formateada podría presentarse así.

Salida: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Una consulta con un JOIN se beneficia aún más de la sangría.

Entrada: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

Una salida legible podría colocar SELECT, FROM, JOIN, ON y WHERE en líneas separadas, manteniendo la comparación o.total > 100. El uso exacto de mayúsculas, el espaciado y la posición de las líneas varían según las convenciones de formato. Considera estos ejemplos como posibles disposiciones, no como un estilo propio garantizado.

¿El formato puede detectar errores de SQL?

No. Embellecer el SQL no equivale a validarlo con el analizador de una base de datos. El resultado declarado de esta herramienta es SQL formateado, por lo que no debe utilizarse como comprobador de sintaxis, verificador de esquemas ni planificador de ejecución.

Aun así, un formato más claro puede revelar posibles errores durante la revisión. Algunos ejemplos habituales son la ausencia de una coma en una lista SELECT, paréntesis sin pareja, una cadena entre comillas sin cerrar, un JOIN sin la condición prevista o una expresión AND u OR agrupada de forma incorrecta. También puede facilitar la detección de una palabra reservada utilizada como identificador sin comillas.

Algunos problemas no pueden confirmarse sin conocer la base de datos de destino. Una sentencia aceptada por PostgreSQL podría necesitar cambios para Microsoft SQL Server, MySQL, Oracle Database o SQLite. Para diagnosticar tablas ausentes, columnas desconocidas, tipos de datos incompatibles y errores de permisos, normalmente se necesita el motor de la base de datos o una herramienta de desarrollo compatible con el dialecto.

¿Cuándo no merece la pena dar formato al SQL?

Por lo general, no es necesario dar formato al SQL si ya presenta un estilo uniforme o si solo lo va a procesar una máquina. Reformatear consultas generadas puede introducir numerosos cambios irrelevantes en el control de versiones sin mejorar el generador que las produjo.

Tampoco suele ser el paso adecuado en estas situaciones:

• Un archivo de migración se ha firmado, tiene una suma de comprobación o se compara de alguna otra forma byte a byte.
• Una consulta minificada o compacta está integrada en un artefacto cuyo tamaño es importante y nadie necesita revisarla.
• La tarea inmediata es validar, analizar el plan de ejecución u optimizar el rendimiento, no mejorar la legibilidad.
• La consulta contiene valores confidenciales que la política de la organización no permite enviar a un servicio alojado en un servidor.

Para aplicar un formato reproducible a todo un repositorio, puede ser más adecuado un formateador de línea de comandos compatible con el dialecto, ya que su configuración puede incluirse en el repositorio junto con el código. Si trabajas con cargas útiles estructuradas de API que contienen SQL, el Validador y formateador de JSON puede ayudarte a revisar el JSON que lo envuelve, aunque el SQL seguirá necesitando un tratamiento específico.

Preguntas frecuentes

¿Dar formato al SQL cambia el comportamiento de NULL?

No. Los espacios en blanco y la sangría no modifican la lógica ternaria de SQL ni el comportamiento de NULL. Aun así, revisa expresiones como column = NULL, que normalmente deben escribirse con IS NULL, porque un formateador no corregirá ese error semántico.

¿Puedo formatear varias sentencias SQL a la vez?

No está documentada la compatibilidad con varias sentencias SQL a la vez. Formatea cada sentencia por separado.

¿Es seguro dejar comentarios en la entrada?

Los comentarios pueden contener referencias a incidencias, nombres de host internos, datos de clientes o notas operativas, incluso cuando el SQL ejecutable no incluye literales sensibles. Revisa tanto los comentarios de línea como los comentarios de bloque antes de enviar el texto al servidor.

¿Las palabras clave de SQL deben escribirse en mayúsculas o minúsculas?

En general, ambos estilos son válidos, ya que muchos motores de bases de datos no distinguen entre mayúsculas y minúsculas en las palabras clave sin comillas. Sigue la convención del repositorio y ten cuidado con los identificadores entre comillas, porque algunas bases de datos conservan o distinguen su combinación de mayúsculas y minúsculas.

¿Qué debo revisar antes de ejecutar la consulta formateada?

Confirma el dialecto de la base de datos de destino, revisa las condiciones WHERE y JOIN y comprueba los límites de las transacciones en sentencias UPDATE, DELETE y de modificación del esquema. Ejecuta primero las consultas arriesgadas en una base de datos de desarrollo o preproducción, preferiblemente con datos representativos y copias de seguridad adecuadas.