¿Cómo hago que las consultas SQL complejas sean más fáciles de escribir? [cerrado]

La mayor parte de esto se basa en solo intentar obtener la respuesta "correcta", por lo que puede descubrir que hay algunos problemas de rendimiento. No tiene sentido acelerar una consulta incorrecta.

Comprenda las relaciones de la tabla : la mayoría serán de una a muchas. Conozca la tabla "muchos". Identifique los campos requeridos para sus uniones.

Piense en los escenarios de incorporación IZQUIERDA : seleccione todos los empleados y su cheque de pago del mes pasado. ¿Qué pasa si no recibieron un cheque de pago el mes pasado?

Conozca el conjunto de resultados: 1) En una hoja de cálculo, ingrese manualmente al menos un registro correcto para su consulta. 2) Escriba la consulta en una forma lo suficientemente simple como para identificar cuántos registros deben devolverse. Use ambos para probar su consulta para asegurarse de que unirse a una nueva tabla no altere el resultado.

Divida su consulta en partes manejables : no tiene que escribirlas todas a la vez. Las consultas complejas a veces solo pueden ser una colección de consultas simples.

Tenga cuidado con los niveles mixtos de agregación : si tiene que colocar valores mensuales, trimestrales y hasta la fecha en el mismo conjunto de resultados, deberá calcularlos por separado en las consultas agrupadas en diferentes valores.

Sepa cuándo UNION A veces es más fácil dividir los subgrupos en sus propias declaraciones selectas. Si tiene una tabla combinada con gerentes y otros empleados, y en cada columna tiene que hacer declaraciones de caso basadas en la membresía en uno de estos grupos, puede ser más fácil escribir una consulta de administrador y una unión a una consulta de empleado. Cada uno contendría su propia lógica. Tener que incluir elementos de diferentes tablas en diferentes filas es un uso obvio.

Fórmulas complejas / anidadas : intente sangrar de manera consistente y no tenga miedo de usar varias líneas. "CASO CUANDO CASO CUANDO CASO CUANDO" te volverá loco. Tómese el tiempo para pensar en esto. Guarda los cálculos complejos para el final. Obtener los registros correctos seleccionados primero. Luego atacas fórmulas complejas sabiendo que estás trabajando con los valores correctos. Ver los valores utilizados en las fórmulas lo ayudará a identificar áreas donde debe tener en cuenta los valores NULL y dónde manejar el error de división por cero.

Realice pruebas a menudo a medida que agrega nuevas tablas para asegurarse de que aún está obteniendo el conjunto de resultados deseado y de saber qué unión o cláusula es la culpable.

1. Indentación sería lo primero que se debe hacer, si no lo estás haciendo ya. No solo es útil incluso con consultas simples, sino que es crucial cuando se trata de uniones y consultas un poco más complejas que un select top 1 [ColumnName] from [TableName] .

2. Una vez sangrada correctamente, nada prohíbe agregar comentarios dentro de la consulta, cuando sea apropiado. No los use en exceso: si el código es lo suficientemente explícito, agregar comentarios solo dañará la claridad del código. Pero aún son bienvenidos para las partes menos explícitas de la consulta.

   Tenga en cuenta que las consultas más largas (incluidas las consultas con comentarios) significarían un mayor uso de ancho de banda entre su servidor de aplicaciones y su servidor de base de datos. También tenga en cuenta que a menos que esté trabajando en un producto a escala de Google con una gran cantidad de solicitudes por segundo, que requieran un rendimiento excepcional y el uso de recursos, el tamaño agregado por los comentarios puede no cambiar nada para usted en términos de rendimiento.

3. Aplicar el mismo estilo sobre tablas, columnas, etc. también ayuda a mejorar la legibilidad. Cuando una base de datos heredada tiene las tablas PRODUCT , users , USERS_ObsoleteDONT_USE , PR_SHIPMENTS y HRhbYd_UU , alguien está haciendo algo muy mal.

4. También es importante imponer el mismo estilo sobre las consultas . Por ejemplo, si está escribiendo consultas para Microsoft SQL Server y decidió usar [TableName] en lugar de TableName , manténgalo. Si va a una nueva línea después de select , no lo haga solo en la mitad de sus consultas, sino en todas.

5. No use * , a menos que haya razones sólidas para hacerlo (como en if exists(select * from [TableName] where ...) en Microsoft SQL Server). No solo * tiene un impacto negativo en el rendimiento de algunas bases de datos (si no la mayoría), sino que tampoco es útil para el desarrollador que usa su consulta. De la misma manera, un desarrollador debe acceder a los valores por nombre, nunca por índice.

6. Finalmente, para las selecciones, no hay nada de malo en proporcionar una vista . Para cualquier otra cosa, procedimientos almacenados también se pueden usar según el proyecto y las personas con las que esté trabajando.

^{¹ Algunas personas odian los procedimientos almacenados. A otros no les gustan por varias razones (perfectamente válidas, al menos por ellas).}

^{² Sus colegas, los otros estudiantes, su profesor, etc.}

Aquí hay un poco de un tiro en la oscuridad, pero si estás escribiendo muchas vistas temporales, quizás no te hayas dado cuenta de que en la mayoría de los lugares puedes poner una tabla en una declaración SQL, esa tabla se puede reemplazar por una consulta. .

Entonces, en lugar de unir la tabla A a la vista temporal B, puede unir la tabla A a la consulta que ha estado utilizando como vista temporal B. Por ejemplo:

    SELECT A.Col1, A.Col2, B.Col1,B.Col2
      FROM (SELECT RealTableZ.Col1, RealTableY.Col2, RealTableY.ID as ID
              FROM RealTableZ 
   LEFT OUTER JOIN RealTableY
                ON RealTableZ.ForeignKeyY=RealTableY.ID
             WHERE RealTableY.Col11>14
            ) As B
        INNER JOIN A
                ON A.ForeignKeyY=B.ID

Este ejemplo es bastante inútil, pero debería explicar la sintaxis.

Para las vistas que no son "especiales" (indexadas, particionadas), esto debería resultar en el mismo plan de consulta que si usara una vista.

Para facilitar la escritura, puede verificar cada pieza para asegurarse de que está obteniendo lo que esperaba antes de escribir la consulta completa.

Mis disculpas si esto ya es viejo para ti.

En lugar de vistas temporales, use la cláusula WITH . Esto hace que sea mucho más fácil dividir las consultas grandes en partes más legibles más pequeñas.

1. Familiarízate con la teoría de conjuntos si aún no lo estás. SQL se basa en la teoría de conjuntos y la comprensión de los conjuntos lo ayudará a familiarizarse con el funcionamiento de SQL.
2. Practique más SQl, si solo está aprendiendo SQL, tomará tiempo entender cómo hacerlo todo, algunas cosas simplemente toman tiempo antes de que realmente las entienda, las uniones son un gran ejemplo cuanto más las use, mejor obtendrá en ello.
3. Asegúrese de que las tablas que está consultando están diseñadas correctamente
4. No tenga miedo de usar vistas en consultas selectas, especialmente si tiene un conjunto común que necesita ser refinado de varias maneras diferentes

Al igual que con cualquier otra cosa, desea dividir el problema en partes manejables.

Por cierto, así es como se resuelven problemas complejos.

Entonces: desea revisar la subconsulta para ver si realmente devuelve lo que desea antes de ejecutar una consulta externa en ella. Quieres probar una combinación mínima de cada mesa en la que te estás uniendo para que puedas ver que realmente lo estás pensando correctamente. Ese tipo de cosas. Esperar escribirlo todo y salir exactamente lo que quieres de un solo golpe no es realista.

Una declaración SQL, una vez que alcanza un cierto nivel de complejidad, es básicamente un pequeño programa en sí mismo. Es una gran diferencia entender realmente cómo se combinan, seleccionan, filtran y generan los datos.