Código de formato de consultas SQL

¿Debo romper las consultas SQL en diferentes líneas? Por ejemplo, en el proyecto en el que estoy trabajando, ¡tenemos una consulta que toma 1600 columnas! Más de 1600 caracteres de tabulación. Escribí consultas como esta:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Pero me exigieron que los pusiera en una línea y dijeron que mi estilo es de mal formato. ¿Por qué es una mala práctica?

Por razones de control de fuente, tenemos saltos de línea después de cada cláusula where o coma. Entonces tu anterior se convierte en

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(la tabulación y la alineación no tienen un estándar aquí, pero las comas generalmente son iniciales)

Aún así, no hay diferencia de rendimiento.

Parece que una consulta de 1600 columnas necesita una revisión seria por parte de un buen DBA.

Si una consulta es compleja, la envolveré. Si es sencillo, lo dejaré como una sola línea a menos que sea demasiado largo, luego comenzaré a envolverlo nuevamente.

Se trata de la capacidad de administración y de comprender lo que se supone que debe hacer, por lo que el ajuste o no ajuste se puede decidir sobre la marcha, a menos que su organización tenga algunas reglas de formato de código al respecto.

Re: siendo una mala práctica de codificación. ¡Apenas! Es muy buena practica. No hay buenas razones que conozco para usar una consulta tan larga, y muchas buenas razones para volver a formatearla. Como dije antes, un DBA experto probablemente necesite trabajar en ello.

La única ventaja de las consultas de línea única que viene a la mente es que esas consultas pueden ser algo más fáciles de entender. Aparte de eso, sin embargo, estoy perplejo. Personalmente, prefiero las consultas divididas más legibles.

Los comentarios de varias líneas son buenos, casi vitales cuando se trata de grandes volúmenes de SQL. Y si su lenguaje de programación tiene citas heredoc, es aún mejor (ya que muchos editores pueden resaltar la sintaxis SQL en ellas).

Ejemplo:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Al trabajar con consultas de docenas de líneas (o cientos), tanto la sangría como el espacio en blanco hacen que el texto sea viable.

Parece que esto se trata específicamente de definir una consulta grande dentro de un lenguaje de programación, ver que colocas la consulta dentro de un literal de cadena y la concatenas.

Si se trata de un lenguaje compilado, no debería haber ninguna diferencia: una de las primeras optimizaciones que haría el compilador es concatenar automáticamente los literales de las cadenas, de modo que termines con una cadena grande de todos modos.

En cuanto a la sintaxis, debería considerar mover la consulta fuera de su código: almacénela en un archivo de recursos .sql separado y haga que su software lea ese archivo. Utilice declaraciones preparadas para las variables, si no se trata de una consulta que se construye dinámicamente (es decir, cláusulas where, etc., agregadas según ciertos parámetros). Si se construye dinámicamente, puede agregar variables de reemplazo propias, insertando parámetros adicionales donde y cuando sea necesario.

En cuanto a las 1600 columnas, recomiendo seriamente construir una vista para eso, así que en lugar de

SELECT column1, column2, .... column1600 from X where Y

obtendrías

SELECCIONE * DESDE viewX DONDE y

Mucho más conciso en su propio código.

A menudo uso el formato presentado por @glasnt para solucionar problemas de una consulta complicada, sin embargo, generalmente tengo consultas en una sola línea.

Es posible que esto no responda a su pregunta, pero también sugeriría dividir su consulta en consultas más pequeñas. Obviamente, esto depende de la consulta, pero cuantas más cláusulas y uniones agregue a su consulta, menos podrá el motor SQL optimizar su consulta.

El proveedor de su base de datos debe tener herramientas como EXPLAIN de MySQL (o la configuración SHOWPLAN_ALL de MSSQL) que le mostrarán qué está haciendo la base de datos detrás de escena para optimizar su consulta, cada vez que la base de datos tiene que crear una tabla temporal o algo así, está agregando grandes retrasos cuando habla de múltiples usuarios concurrentes.

Al mover lo que podría parecer una lógica trivial fuera del SQL y en su código, puede proporcionar incrementos drásticos en el rendimiento: SQL es excelente en operaciones simples.

El beneficio obvio de esto, ya que podría relacionarse con usted, es que sus consultas son mucho menos complejas y fáciles de leer, fáciles de administrar (no> 1600 columnas) y más rápidas. Definitivamente una victoria completa.

Espero que esto ayude :)