Cómo formatear SQL con sangría y palabras clave en mayúsculas

Qué puedes hacer con SQL Formatter

SQL Formatter sirve para convertir una cadena de SQL difícil de leer en una versión reindentada, con las palabras clave en mayúsculas y los distintos enunciados separados de forma uniforme. Es útil antes de revisar una consulta, compartirla con el equipo o incorporarla a una documentación técnica, pero trabaja sobre el texto proporcionado: no ejecuta consultas ni comprueba sus resultados.

Cómo formatear una consulta SQL

1. Introduce el SQL como texto. La entrada es opcional y, si la dejas vacía, se utiliza un valor vacío. Si solo contiene espacios en blanco, el resultado formateado queda vacío. En una integración que todavía use el argumento antiguo sql, ese valor se toma como alternativa cuando la entrada principal está vacía.

2. Indica la sangría que prefieras. El valor predeterminado es 2. Para una entrada que no sea solo espacios, se convierte a un número entero: los valores inferiores a 0, superiores a 8 o que no se puedan convertir vuelven a 2. Con una entrada formada únicamente por espacios, esta conversión no se realiza.

3. Puedes proporcionar un dialecto, pero úsalo solo como un dato de entrada general. El formateo descrito no aplica reglas específicas de cada dialecto.

4. Ejecuta el formateo y revisa el texto devuelto. Si se reconocen uno o varios enunciados, se reindentan, las palabras clave SQL pasan a mayúsculas y los enunciados se unen con un punto y coma, un salto de línea y un punto y coma final.

5. Comprueba que el contenido recibido sea una cadena y que no supere 1.000.000 de bytes UTF-8 cuando no esté vacío. Una entrada de otro tipo o demasiado grande se rechaza antes del formateo.

Cómo interpretar el resultado

El resultado es una presentación más legible del SQL, no una validación de la consulta. La presencia de palabras clave en mayúsculas y de una sangría ordenada indica que se ha aplicado el formato, pero no demuestra que la consulta pueda ejecutarse ni que devuelva datos correctos.

Si el resultado aparece vacío, revisa si la entrada solo contenía espacios. Con SQL no vacío, el formateo también puede fallar si no se detectan enunciados, si la biblioteca de análisis no está disponible o si se produce una excepción durante el análisis o el formateo. En esos casos, conserva el texto original y revisa la entrada antes de volver a intentarlo.

El campo de dialecto no debe interpretarse como una selección de reglas para PostgreSQL, MySQL, SQL Server u otros sistemas. La implementación descrita acepta ese valor, pero no aplica un análisis ni un formateo específico por dialecto.

Ejemplo práctico

Una persona quiere dejar legible una consulta breve antes de incluirla en una revisión técnica.

Introduce select id,name from users where active=1, establece una sangría de 4 y ejecuta el formateo. Después, revisa la salida sin intentar usarla como validación de los datos.

El resultado conserva la estructura de los enunciados reconocidos, muestra las palabras clave en mayúsculas, aplica sangría y termina con un punto y coma; los enunciados quedan separados por un punto y coma y un salto de línea.

Limitaciones

• No aplica reglas específicas de dialecto y el formateo de una entrada no vacía puede fallar si no se detectan enunciados, falta la biblioteca de análisis o aparece una excepción.

Errores frecuentes

• Un error habitual es introducir una sangría no numérica o fuera del intervalo permitido y esperar que se conserve. Para una entrada SQL no vacía, usa un entero entre 0 y 8; de lo contrario, se aplica 2.

Preguntas frecuentes

¿Qué hace SQL Formatter con una consulta SQL?

Cuando la entrada contiene SQL no vacío, se reindentan los enunciados reconocidos y las palabras clave pasan a mayúsculas. Una entrada formada solo por espacios produce un resultado vacío.

¿Qué valor de sangría debo usar?

Si el SQL no está vacío, puedes indicar un valor entre 0 y 8. Los valores no convertibles o fuera de ese intervalo se sustituyen por 2; con una entrada de solo espacios, la conversión no se realiza.

¿El campo de dialecto adapta el resultado a PostgreSQL o MySQL?

El campo se acepta, pero el formateo descrito no aplica reglas específicas del dialecto. Por tanto, no debe usarse como prueba de compatibilidad con un sistema de base de datos concreto.