Tome una consulta de inserción de SQL bastante típica con parámetros en un proyecto de C# usando NHibernate; podría escribirse así:
Session .CreateSQLQuery( @"INSERT INTO my_table(COL_A, COL_B, ..., ..., COL_M, COL_N) VALUES (:VAL_A, :VAL_B, ...., ..., :VAL_M, :VAL_N)") .SetParameter("VAL_A", "input for A") .SetParameter("VAL_B", "input for B") (...) .SetParameter("VAL_N", "input for N") .ExecuteUpdate();Esto se siente bastante bien organizado y fácil de leer para mí, lo que me gusta, pero tengo curiosidad sobre el espacio en blanco incluido con la consulta en sí. Podríamos eliminarlo escribiendo alguna variación de lo siguiente, que he visto en algunos casos. Sin embargo, esto requiere un poco más de esfuerzo para escribir y puede afectar la legibilidad:
Session .CreateSQLQuery( @"INSERT INTO my_table(COL_A, COL_B, ..., " + @" COL_M, COL_N)" + @" VALUES (:VAL_A, :VAL_B, ....," + @" :VAL_M, :VAL_N)") .SetParameter(...)Mi pregunta entonces es si tiene algún sentido hacer algo como esto.
Tengo un vago recuerdo de haber oído hablar de esto hace años; la idea de que deberíamos limitar la cantidad de espacios en blanco, ya que podría afectar el rendimiento de las consultas. Mi corazonada es que el efecto de esto (si lo hay) sería insignificante, y que no valdría la pena el costo, pero sería interesante obtener un poco más de información.
Cambiar los espacios en blanco no afecta directamente el rendimiento de Oracle SQL, pero puede afectarlo indirectamente al evitar las características de rendimiento de SQL. Pero incluso si hay una extraña razón por la que esta consulta sufre debido a la adición de espacio, en general no debe dejar de formatear su SQL.
Algunas funciones de optimización de SQL, como perfiles y esquemas de SQL, se basan en un hash MD5 del texto de la instrucción SQL. Cualquier cambio en la declaración, incluso agregar o eliminar un espacio, generará un hash diferente. Si un DBA o la tarea del asesor de ajuste ha creado un perfil de SQL que mejora el rendimiento de una declaración, ese perfil ya no funcionará después de cualquier cambio trivial en la consulta.
Se produce un problema relacionado con la reoptimización de SQL. El optimizador aprende de sus errores y puede cambiar el plan de ejecución la segunda o tercera vez que se ejecuta la instrucción. En raras ocasiones, el optimizador aprenderá la lección equivocada y una instrucción SQL será más lenta en la segunda o tercera ejecución. En ese caso, agregar o eliminar un espacio hará que la consulta se ejecute más rápido, al menos inicialmente.
Estas optimizaciones detrás de escena son herramientas poderosas para mejorar el rendimiento de las consultas sin cambiar las consultas. Desafortunadamente, también tienden a crear mitos de programación de culto de carga; alguien hace un cambio trivial, el rendimiento mejora y cree que se ha topado con un secreto de rendimiento críptico. Probablemente así es como comenzó todo el sinsentido de "usar contar (1) en lugar de contar (*)".
Siga usando todos los espacios en blanco que necesita para formatear correctamente sus consultas. Si se encuentra con un problema real y medible, compare los planes de ejecución para ver qué cambió y por qué. Si un compañero de trabajo insiste en eliminar los espacios en blanco como regla general, pídale un caso de prueba reproducible para probar sus afirmaciones.
No. Las sentencias SQL se "compilan" de manera efectiva antes de ejecutarse y los espacios en blanco no tienen un efecto tangible en el resultado, a menos que la falta de ellos introduzca un error de sintaxis.