DeveloTools

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.

100% client-side

Consulta SQL (SELECT, UPDATE o DELETE)

0 caracteres

Consulta formateada


      
—

    


    

      

        
Diagrama de árbol de consulta

        

          
          100%
          
          
          
          
        

      

      

        
        Soporta SELECT, UPDATE y DELETE como un árbol: la consulta es la raíz, y fuentes/WHERE/HAVING/GROUP BY/ORDER BY/LIMIT se ramifican hacia la derecha. CREATE/INSERT y otro DDL quedan fuera de alcance — un diagrama de esquema (ER) es un tipo de herramienta distinto. CTEs y UNION tampoco se interpretan — ver las preguntas frecuentes abajo.
      

      

        
        
      

      

      
      
—

    


    

      
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.

      

    


    

      
Herramientas relacionadas