SQL Query Visualizer
Mirá una sentencia SQL SELECT, UPDATE o DELETE como un árbol — la consulta como raíz, cada cláusula ramificándose hacia la derecha — en vez de texto formateado.
Consulta SQL (SELECT, UPDATE o DELETE)
Consulta formateada
Diagrama de árbol de consulta
¿Qué es SQL Query Visualizer?
SQL es el lenguaje que se usa para pedirle datos a una base de datos (SELECT), o para modificarlos (UPDATE, DELETE). Una sola consulta SQL puede meter mucha lógica —joins, filtros, subconsultas anidadas— en un bloque de texto denso y difícil de leer de un vistazo. SQL Query Visualizer interpreta una consulta y la dibuja como un diagrama de árbol ramificado, para que puedas ver cómo se relacionan sus cláusulas de forma visual en vez de interpretar el texto mentalmente.
Cómo usar SQL Query Visualizer
- Pegá una sentencia SELECT, UPDATE o DELETE en el panel Consulta SQL, o hacé clic en Ejemplo para cargar una de muestra.
- Elegí el Dialecto (Genérico/ANSI, MySQL, PostgreSQL, SQL Server) que corresponda a la sintaxis de tu consulta.
- Revisá el panel Consulta formateada para ver una versión prolija e indentada de tu SQL.
- Explorá el Diagrama de árbol de consulta debajo — usá Alejar/Acercar, Ajustar o Pantalla completa para moverte por un árbol grande.
- Hacé clic en PNG para descargar el diagrama como imagen.
Cómo funciona el diagrama de árbol de consulta
Esta herramienta corre un parser recursive-descent escrito a mano sobre tu SQL — no reformatea texto como un pretty-printer, construye un árbol de sintaxis abstracta (AST) real y lo dispone con RAÍZ EN LA CONSULTA MISMA, creciendo de izquierda a derecha. El nodo principal de la sentencia — la lista de columnas de SELECT, el SET de UPDATE, el marcador de DELETE — es la raíz, dibujada en el extremo izquierdo; cada cláusula es un hijo directo que se ramifica hacia la derecha, igual que un dendrograma o un organigrama, solo que rotado 90° para crecer hacia los costados en vez de hacia abajo:
-- Antes (SQL en texto plano)
SELECT id FROM orders
WHERE (status = 'active' OR status = 'pending')
AND created_at > '2024-01-01'
-- Después (un árbol, raíz a la izquierda, ramificándose a la derecha)
SELECT (raíz)
+- FROM orders
+- WHERE
+- AND
+- OR ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
| +- status='active' ┊
| +- status='pending' ┊ (punteado: paréntesis explícitos)
| ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
+- created_at > '2024-01-01'
El contorno punteado alrededor de la rama OR es exactamente lo que significaban los paréntesis en tu consulta: sin ellos, a OR b AND c se interpretaría como a OR (b AND c), porque AND tiene mayor precedencia que OR en cualquier dialecto SQL — el diagrama hace visible esa precedencia en vez de dejarla librada a la lectura del texto. UPDATE y DELETE siguen el mismo modelo: su(s) tabla(s) destino y la cláusula WHERE se ramifican desde la raíz exactamente igual, terminando en una raíz SET o DELETE en vez de una proyección SELECT.
Preguntas frecuentes
¿Qué SQL soporta esta herramienta?
Sentencias SELECT, UPDATE y DELETE: para SELECT, la lista de columnas (incluyendo *, table.*, alias, aritmética y funciones como COUNT(id)), FROM con varias tablas separadas por coma, cadenas de JOIN INNER/LEFT/RIGHT/FULL/CROSS con su condición ON, WHERE y HAVING con agrupación AND/OR/NOT completa, GROUP BY, ORDER BY, LIMIT/OFFSET/TOP, y subconsultas en FROM, en WHERE (IN o EXISTS) o como valor de una columna. UPDATE (SET, FROM opcional, WHERE) y DELETE (USING opcional, WHERE) usan el mismo modelo de árbol. CREATE, INSERT y otro DDL están deliberadamente fuera de alcance: un diagrama de esquema (ER) es un problema de visualización distinto, no una versión más chica de esta herramienta, así que ese tipo de entrada muestra un mensaje claro y específico en vez de un diagrama incorrecto. Los CTEs (WITH), UNION y funciones de ventana tampoco se interpretan todavía.
¿Por qué SELECT (o SET / DELETE) se dibuja como raíz, y no FROM?
El diagrama es un árbol con raíz, no un diagrama de flujo: el nodo principal de la sentencia — la proyección de SELECT, el SET de UPDATE, el marcador de DELETE — queda a la izquierda como raíz, y cada cláusula (fuentes, WHERE/HAVING con sus subárboles AND/OR, GROUP BY, ORDER BY, LIMIT) es un hijo directo que se ramifica hacia la derecha, igual que un dendrograma o un organigrama — solo que rotado para crecer hacia la derecha en vez de hacia abajo. Es una decisión deliberada: se lee como "esta es la consulta, y estas son sus partes", en vez de un flujo de datos de izquierda a derecha.
¿Cómo muestra el diagrama la lógica AND vs OR?
WHERE, HAVING y la condición ON de cada JOIN se dibujan como una caja compacta que a su vez se ramifica hacia la derecha en su propio árbol de condiciones AND/OR: AND y OR tienen cada uno su propio nodo conector, y los paréntesis explícitos alrededor de un grupo se dibujan como un contorno punteado alrededor de todo ese subárbol — así (a OR b) AND c muestra visiblemente el OR agrupado por separado del AND externo.
¿Cómo se muestran las subconsultas?
Una subconsulta se interpreta con el mismo parser, de forma recursiva, y se renderiza como su propio árbol anidado — con su propia raíz, sus propias ramas — dentro de un panel claramente delimitado con borde punteado, subordinado de forma evidente al FROM, WHERE o columna al que pertenece, sin importar cuán profundo sea el anidamiento.
¿El selector de dialecto soporta completamente MySQL, PostgreSQL y SQL Server?
No — está honestamente acotado a la única diferencia estructural que realmente cambia el parseo: la sintaxis de límite de filas. Generic/ANSI y PostgreSQL usan LIMIT n OFFSET m, MySQL usa el mismo LIMIT/OFFSET, y SQL Server usa TOP n (justo después de SELECT) u OFFSET m ROWS FETCH NEXT n ROWS ONLY. El uso de comillas para identificadores ("dobles", `backtick`, [corchetes]) se acepta de forma flexible en todos los dialectos. Funciones propietarias, tipos de datos y otra sintaxis específica del motor no se modelan.
¿Mi SQL se envía a algún lado?
No. El formateo, el parseo y el renderizado ocurren enteramente en tu navegador con JavaScript nativo; nada se sube nunca a un servidor.