indentar - Formato de consultas SQL claras y legibles

indentar codigo sql server

Question

Estoy escribiendo algunas consultas SQL con varias subconsultas y muchas uniones en todas partes, tanto dentro de la subconsulta como en la tabla resultante de la subconsulta.

No estamos usando vistas, así que eso está fuera de discusión.

Después de escribirlo, lo estoy mirando y rascándome la cabeza preguntándome qué está haciendo porque no puedo seguirlo.

¿Qué tipo de formato utilizas para intentar limpiar ese desorden? ¿Tal vez sangrías?

Answer 1

Chico es esta una pregunta cargada. :) Hay tantas formas de hacerlo correctamente como personas inteligentes en este sitio. Dicho esto, aquí es cómo me mantengo sano cuando construyo sentencias complejas de SQL:

select
    c.customer_id
   ,c.customer_name
   ,o.order_id
   ,o.order_date
   ,o.amount_taxable
   ,od.order_detail_id
   ,p.product_name
   ,pt.product_type_name
from
    customer c
inner join
    order o
    on c.customer_id = o.customer_id
inner join
    order_detail od
    on o.order_id = od.order_id
inner join
    product p
    on od.product_id = p.product_id
inner join
    product_type pt
    on p.product_type_id = pt.product_type_id
where
    o.order_date between ''1/1/2011'' and ''1/5/2011''
and
    (
        pt.product_type_name = ''toys''
     or
        pt.product_type_name like ''%kids%''
    )
order by
    o.order_date
   ,pt.product_type_name
   ,p.product_name

Si está interesado, puedo publicar / enviar diseños para inserciones, actualizaciones y eliminaciones, así como subconsultas correlacionadas y complejos predicados de unión.

¿Responde esto a tu pregunta?

Answer 2

En general, sigo un conjunto jerárquico simple de reglas de formato. Básicamente, palabras clave como SELECT, FROM, ORDER BY van en su propia línea. Cada campo va en su propia línea (de manera recursiva)

SELECT 
    F.FIELD1,
    F.FIELD2,
    F.FIELD3
FROM
    FOO F 
WHERE 
    F.FIELD4 IN 
    (
        SELECT 
            B.BAR
        FROM 
            BAR B
        WHERE
            B.TYPE = 4
            AND B.OTHER = 7
    )

Answer 3

Generalmente, la gente rompe líneas en palabras reservadas y sangra cualquier subconsulta:

SELECT *
FROM tablename
WHERE value in
   (SELECT *
   FROM tablename2 
   WHERE condition)
ORDER BY column

Answer 4

Indenting ciertamente, pero también puede dividir las subconsultas con comentarios, hacer que los nombres de sus alias sean realmente significativos y especificar a qué subconsulta se refieren, por ejemplo, innerCustomer, outerCustomer.

Common Table Expressions realmente puede ayudar en algunos casos a dividir una consulta en secciones significativas.

Answer 5

La única forma verdadera y correcta de formatear SQL es:

SELECT t.mycolumn        AS column1
      ,t.othercolumn     AS column2
      ,SUM(t.tweedledum) AS column3
FROM   table1 t
      ,(SELECT u.anothercol
              ,u.memaw                  /*this is a comment*/
        FROM   table2       u
              ,anothertable x
        WHERE  u.bla       = :b1        /*the bla value*/
        AND    x.uniquecol = :b2        /*the widget id*/
       ) v
WHERE  t.tweedledee = v.anothercol
AND    t.hohum      = v.memaw
GROUP BY t.mycolumn
        ,t.othercolumn
HAVING COUNT(*) > 1
;

;)

Sin embargo, en serio, me gusta usar cláusulas WITH (como ya se sugirió) para domesticar consultas SQL muy complicadas.

Answer 6

Los alias de la tabla y la consistencia simple lo llevarán a un largo, largo camino

Lo que parece decente es romper líneas en las palabras clave SELECT, FROM, WHERE (etc.).

Las uniones pueden ser más complicadas, sangrar la parte ON de las uniones resalta la parte importante de la misma al frente.

Romper expresiones lógicas complicadas (unir y donde ambas condiciones) en el mismo nivel también ayuda.

Sangrando lógicamente el mismo nivel de declaración (subconsultas, paréntesis de apertura, etc.)

Poner en mayúscula todas las palabras clave y funciones estándar.

El SQL realmente complejo no se alejará de los comentarios, aunque normalmente los encontrará en scripts SQL y no en SQL dinámico.

Ejemplo de edición:

SELECT a.name, SUM(b.tax)
FROM   db_prefix_registered_users a 
       INNER JOIN db_prefix_transactions b 
           ON a.id = b.user_id
       LEFT JOIN db_countries
           ON b.paid_from_country_id = c.id
WHERE  a.type IN (1, 2, 7) AND
       b.date < (SELECT MAX(date) 
                 FROM audit) AND
       c.country = ''CH''

Entonces, al final para resumirlo, la consistencia es lo más importante.

Answer 7

Me gusta usar algo como:

SELECT    col1,
          col2,
          ...
FROM
    MyTable as T1
INNER JOIN
    MyOtherTable as T2
        ON t1.col1 = t2.col1
        AND t1.col2 = t2.col2
LEFT JOIN
    (   
        SELECT 1,2,3
        FROM Someothertable
        WHERE somestuff = someotherstuff
    ) as T3
    ON t1.field = t3.field

Answer 8

Póngalo en una vista para que sea más fácil de visualizar, tal vez mantenga una captura de pantalla como parte de la documentación. No tiene que guardar la vista ni usarla para ningún otro propósito.

Answer 9

Una pregunta histórica con mil opiniones y ninguna respuesta correcta, y una de mis favoritas. Aquí están mis dos centavos.

En lo que respecta a las subconsultas, últimamente me ha resultado más fácil seguir lo que está pasando con sangría "extrema" y agregar comentarios de esta manera:

SELECT mt.Col1, mt.Col2, subQ.Dollars
 from MyTable1 mt
  inner join (--  Get the dollar total for each SubCol
              select SubCol, sum(Dollars) Dollars
               from MyTable2
               group by SubCol) subQ
   on subQ.SubCol = mt.Col1
 order by mt.Col2

En cuanto al otro centavo, solo uso mayúsculas en la primera palabra. Con las páginas de consultas de ejecución, hace que sea un poco más fácil elegir cuándo comienza una nueva.

Su kilometraje, por supuesto, variará.

Answer 10

Wow, muchas respuestas aquí, pero una cosa que no he visto en muchas son COMENTARIOS! Tiendo a agregar muchos comentarios a lo largo, especialmente con grandes sentencias de SQL. El formato es importante, pero los comentarios bien colocados y significativos son extremadamente importantes, no solo para usted, sino también para la pobre alma que necesita mantener el código;)

Answer 11

Con consultas grandes, tiendo a confiar mucho en conjuntos de resultados con nombre usando WITH . Esto permite definir el conjunto de resultados de antemano y simplifica la consulta principal. Los conjuntos de resultados con nombre pueden ayudar a hacer que el plan de consulta sea más eficiente, por ejemplo, postgres almacena el conjunto de resultados en una tabla temporal.

Ejemplo:

WITH 
  cubed_data AS (
     SELECT 
        dimension1_id,
        dimension2_id,
        dimension3_id,
        measure_id,
        SUM(value) value
     FROM
        source_data
     GROUP BY
        CUBE(dimension1, dimension2, dimension3),
        measure
  ), 
  dimension1_label AS(
     SELECT 
        dimension1_id,
        dimension1_label
     FROM 
        labels 
     WHERE 
        object = ''dimension1''
  ), ...
SELECT 
  *
FROM  
  cubed_data
  JOIN dimension1_label USING (dimension1_id)
  JOIN dimension2_label USING (dimension2_id)
  JOIN dimension3_label USING (dimension3_id)
  JOIN measure_label USING (measure_id)

El ejemplo es un poco artificial, pero espero que muestre un aumento en la claridad en comparación con las subconsultas en línea. Los conjuntos de resultados con nombre me han sido de gran ayuda cuando he estado preparando datos para el uso de OLAP. Los conjuntos de resultados con nombre también son obligatorios si tiene / desea crear consultas recursivas.

WITH funciona al menos en las versiones actuales de Postgres, Oracle y SQL Server