Te recomendamos que revises esta solución en un ambiente controlado antes de pasarlo a producción, saludos.
Solución:
Voy a estar en desacuerdo sobre consultas grandes y complicadas con datagod aquí. Los veo solo como problemas si están desorganizados. En cuanto al rendimiento, casi siempre son mejores porque el planificador tiene mucha más libertad para recuperar la información. Sin embargo, las consultas grandes deben escribirse teniendo en cuenta la mantenibilidad. En general, descubrí que SQL simple y bien estructurado es fácil de depurar incluso cuando una sola consulta dura más de 200 líneas. Esto se debe a que, por lo general, tiene una idea bastante buena de qué tipo de problema está tratando, por lo que solo hay algunas áreas en la consulta que debe verificar.
Los problemas de mantenimiento, IME, surgen cuando la estructura de SQL se descompone. Las consultas largas y complejas en las subselecciones perjudican la legibilidad y la solución de problemas, al igual que las vistas en línea, y ambas deben evitarse en las consultas largas. En su lugar, use VIEW si puede (tenga en cuenta que si está en MySQL, las vistas no funcionan tan bien, pero en la mayoría de los otros db lo hacen) y use expresiones de tabla comunes donde no funcionan (MySQL no es compatible con estos por cierto).
Las consultas largas y complejas funcionan bastante bien tanto en un caso de mantenimiento como de rendimiento en el que mantiene sus cláusulas where simples y en el que hace todo lo que puede con uniones en lugar de subselecciones. El objetivo es hacer que “los registros no se muestren” le brinde algunos lugares muy específicos en la consulta para verificar (¿se descarta en una combinación o se filtra en una cláusula Dónde?) y así el equipo de mantenimiento realmente puede mantener las cosas.
En cuanto a la escalabilidad, tenga en cuenta que cuanta más flexibilidad tenga el planificador, eso también es algo bueno….
Editar: Menciona que esto es MySQL, por lo que es poco probable que las vistas funcionen tan bien y los CTE están fuera de discusión. Además, el ejemplo dado no es particularmente largo o complejo, por lo que no hay problema.
Como alguien que tiene que respaldar/limpiar estas consultas grandes y complicadas, diría que es mucho mejor dividirlas en varios fragmentos pequeños fáciles de entender. No lo es necesariamente mejor desde el punto de vista del rendimiento, pero al menos le está dando a SQL una mejor oportunidad de generar un buen plan de consulta.
Haz la vida más fácil a las personas que te siguen, y dirán cosas buenas de ti. Hazlo difícil para ellos y te maldecirán.
Mis 2 centavos en las 2 palabras clave consulta-rendimiento y escalabilidad:
Rendimiento de consultas:
El paralelismo de SQL Server ya hace un muy buen trabajo al dividir las consultas en búsquedas de subprocesos múltiples, por lo que no estoy seguro de la mejora del rendimiento de las consultas que verá al hacerlo para SQL Server. Sin embargo, tendrá que mirar el plan de ejecución para ver cuánto grado de paralelismo obtiene cuando lo ejecuta y comparar los resultados en ambos sentidos. Si termina teniendo que usar una sugerencia de consulta para obtener el mismo o mejor rendimiento, entonces, en mi opinión, no vale la pena, ya que la sugerencia de consulta podría no ser óptima más adelante.
Escalabilidad:
Leer las consultas puede ser más fácil como dijo datagod, y dividirlas en consultas separadas tiene sentido si también puede usar sus nuevas consultas en otras áreas, pero si no las va a usar para otras llamadas también, entonces es Habrá aún más procesos almacenados para administrar para 1 tarea y, en mi opinión, no contribuiría a la escalabilidad.
Te mostramos reseñas y puntuaciones
Al final de todo puedes encontrar las críticas de otros desarrolladores, tú asimismo eres capaz dejar el tuyo si lo crees conveniente.