No tengo demasiada experiencia con SQL. La mayoría de las consultas que he escrito han sido muy pequeñas. Cada vez que veo una consulta muy grande, siempre asumo que debe ser optimizada. ¿Pero es esto cierto? ¿o hay situaciones en las que las consultas realmente grandes son solo lo que se necesita?¿existe algo así como una consulta demasiado grande?
cierto cuando digo grandes me refiero a consultas consultas que exceden de 1000 caracteres
Sí, cualquier declaración, método, o incluso de consulta puede ser "demasiado grande".
El problema, en realidad es definir qué es demasiado grande realmente es.
Si no puede sentarse y descubrir qué hace la consulta en un tiempo relativamente corto, probablemente sea mejor dividirla en trozos más pequeños.
Siempre me gusta mirar las cosas desde el punto de vista del mantenimiento. Si la consulta es difícil de entender ahora, ¿qué sucede si tiene que depurar algo en ella?
El hecho de que vea una consulta grande, no significa que deba ser modificada u optimizada, pero si es demasiado complicada para su propio bien, entonces es posible que desee considerar la refactorización.
+1 para "Si la consulta es demasiado difícil de entender ahora ..." Odio mantener cosas que ni siquiera tenían sentido para el autor cuando lo escribió hace diez años. –
@David: "la consulta es demasiado difícil de entender" se basa en el conocimiento de quién está revisando el código. No es bueno si esa persona tiene un conocimiento limitado del tema. –
Sugeriría que no son los personajes los que deben medir el tamaño/complejidad de la consulta.
Me reducirlo a:
Donde trabajo hemos creado procedimientos almacenados que superan los 1000 caracteres. Realmente no puedo decir que fuera NECESARIO, pero a veces la celeridad gana sobre la eficiencia (sobre todo cuando se necesita una solución rápida para un cliente).
Habiendo dicho eso ... si tuviera el tiempo, trataría de optimizar una consulta tan pequeña/eficiente como pueda sin ser demasiado confusa. Utilicé procedimientos almacenados anidados para aclarar un poco las cosas y/o las funciones.
Al igual que en otros idiomas, no puede determinar la eficacia de una consulta basada en el recuento de caracteres. Además, 1000 caracteres no es lo que podría llamar "grande", especialmente cuando utiliza buenos nombres de tabla/columna, alias que tienen sentido, etc.
Si no es lo suficientemente cómodo con SQL para poder " eye ball "los méritos del diseño de una consulta particular, ejecútelo a través de un generador de perfiles y examine el plan de ejecución. Eso te dará una buena idea de los problemas que sufrirá el código en cuestión.
Mi regla general es la siguiente: escribir el mejor apretado, código, más simple que pueda, y optimizar donde sea necesario - es decir, donde se ve un cuello de botella o donde (como sucede con frecuencia) bofetada a sí mismo en la cabeza y di "¡OH!" alrededor de las tres de la mañana de vacaciones.
Resumen: Codifique bien y optimice donde sea necesario.
Como dijo Robert, si no puede determinar fácilmente qué está haciendo la consulta, probablemente deba simplificarse.
+1 Definitivamente es bueno sentirse cómodo leyendo los planes de ejecución de su servidor. – Seth
El número de caracteres no quiere decir que una consulta debe ser optimizado - que es lo que ves dentro de esos personajes que lo hace.
Las cosas como las subconsultas en la parte superior de las subconsultas es algo que revisaría. También revisaría JOINs, pero no debería tomar mucho tiempo comparar con el ERD para saber si hay un JOIN innecesario: lo primero que vería serían las tablas que se unen pero no se usan en el resultado, que es bien si las tablas son tablas link/corrollary/etc.
Si está acostumbrado a escribir cosas simples, es posible que no se dé cuenta de cuán complejo puede ser obtener información para un informe complejo. Sí, las consultas pueden ser largas y complicadas, y aún funcionan bien según lo que se les pide que hagan. A menudo, las técnicas que se utilizan para ajustar el rendimiento pueden hacer que el código parezca más complicado para los menos familiarizados con las técnicas de consulta avanzada. Lo que cuenta es cuánto tiempo lleva ejecutar y si devuelve los datos correctos, no cuántos caracteres tiene.
Cuando veo una consulta compleja, mi primer pensamiento es ¿devuelve lo que el desarrollador realmente tenía la intención de devolver (le sorprendería la frecuencia con la que la respuesta es no) y luego miro para ver si podría hacerlo? estar atentos al rendimiento. Sí, hay muchas consultas largas mal escritas, pero también hay tantas o más que hacen lo que se supone que deben hacer tan rápido como se puede hacer sin un rediseño importante de la base de datos o un hardware más rápido.
En realidad termino con grandes consultas CUANDO sintonizo un fragmento de código. En mi experiencia, la mayor parte del tiempo una gran declaración de SQL es más rápida que el equivalente en múltiples instrucciones/procedimientos almacenados –
Estoy de acuerdo con Jens, según mi experiencia, el SQL de performance_tuned a menudo es más largo que el deficiente rendimiento. – HLGEM