¿Son siete uniones internas en una consulta demasiado?

Question

Tengo una consulta que tiene 7 uniones internas (debido a que gran parte de la información se distribuye en otras tablas), algunos compañeros de trabajo se han sorprendido. Me preguntaba si deberían sorprenderse o tener 7 uniones internas normales.

Answer 1

no es insólito, pero lo ubicaría en una vista para facilitar su uso y mantenimiento

Answer 2

Dos preguntas:

1. ¿Funciona?
2. ¿Puedes explicarlo?

Si es así, entonces siete está bien. Si no puede explicar la consulta, entonces siete es demasiado.

Answer 3

Es normal si su esquema se encuentra en 5ª forma normal :)

Answer 4

Dependiendo de lo que esté intentando lograr, una gran cantidad de combinaciones en una consulta no es notable.

Personalmente, me preocuparía menos la cantidad de combinaciones empleadas para devolver un conjunto de resultados deseado y me preocuparía más si la consulta está optimizada y se ejecuta dentro de los parámetros aceptables.

Si la consulta está totalmente optimizada y no se puede recortar, pero la consulta en sí misma no se ejecuta con la suficiente rapidez, es posible que el diseño de la estructura de datos no sea el adecuado para lo que está intentando hacer. En qué momento puede volver a evaluar lo que está intentando lograr o la estructura de los datos que alimenta su modelo de negocio.

Answer 5

No es para nada inusual. Con un sistema como Siebel es común ver conteos de uniones en cifras dobles.

Answer 6

Siete combinaciones lo hacen más difícil para la lectura, pero más importantes son el rendimiento y la escalabilidad. Si están bien, hazlo.

Answer 7

Probablemente no sea normal pero ciertamente no es excesivo. Si te encuentras uniendo las mismas tablas una y otra vez, crea algunas vistas.

Answer 8

la cantidad de combinaciones depende de su modelo de datos, 7 combinaciones pueden estar en su consulta si eso es lo que usted consulta; recuerdo haber tenido consultas similares en una aplicación en la que trabajé hace mucho tiempo, el rendimiento depende de muchos factores (tabla Tamaño, índices, carga del servidor, configuración del servidor por nombrar algunos) y no creo que se pueda generalizar que las 7 uniones son malas.

si funciona para ti, entonces supongo que está bien: D

Answer 9

Sí, es normal, pero, en realidad, no es una gran idea desde la perspectiva del rendimiento. Ya que los planes de consulta se basan en los costos estimados , hay un aumento en el número de errores a medida que aumenta las uniones (o cualquier otro operador, en este caso):

  

El Optimizador de consultas de SQL Server estimará un mínimo de una fila que sale de un operador de búsqueda. Esto se hace para evitar el caso cuando se selecciona un subárbol muy costoso debido a una subestimación de la cardinalidad. Si se estima que el subárbol devuelve cero filas, muchos planes cuestan aproximadamente lo mismo y, como resultado, puede haber errores en la selección del plan. Por lo tanto, notará que la estimación es & # 8220; alta & # 8221; Para este caso, y algunos errores pueden resultar. También puede observar que estimamos 20 ejecuciones de esta rama en lugar de las 10 reales. Sin embargo, dado el número de combinaciones que se han evaluado antes de este operador, no se considera un factor de 2 (10 filas) & n. ser demasiado malo ( Los errores pueden aumentar exponencialmente con el número de combinaciones ).

Además, el optimizador intenta equilibrar el tiempo requerido para elaborar un plan frente a los posibles ahorros: no pasará todo el día tratando de encontrar el plan más óptimo. Cuantas más combinaciones haya, mayor será el número de planes alternativos, algunos de los cuales pueden ser más óptimos de lo que el optimizador tiene tiempo de encontrar.

Answer 10

7 o incluso más no es en absoluto inusual en los almacenes de datos donde una tabla de hechos podría fácilmente tener claves externas a una docena de dimensiones. En el escenario del almacén de datos, la cardinalidad de las dimensiones suele ser baja en comparación con la tabla de hechos, por lo que los filtros en las dimensiones ayudan a utilizar la tabla de hechos a través de una búsqueda o exploración de índice.

Para un esquema transaccional normalizado, no suele ser un problema si la cardinalidad del conjunto de resultados es baja en la tabla base principal (es decir, selecciona todo sobre un cliente), porque las claves externas normalmente pueden dar como resultado búsquedas de índice o exploraciones de índice.

Answer 11

7 está bien si el diseño de su base de datos lo requiere. Sin embargo, si 7 es necesario para lograr su objetivo, volvería a examinar el diseño de la base de datos para asegurarse de que este nivel de oscuridad sea realmente necesario.

Por curiosidad, ¿es este DB2? Solo un patrón que he notado :)

Answer 12

¿hay 7 combinaciones internas en la misma tabla, 7 combinaciones internas en diferentes tablas o 7 anidadas combinaciones internas?

... pregunta de truco! Realmente no importa, si eso es lo que requiere la estructura de su base de datos, entonces es correcta

advertencia: si hay 7 combinaciones internas anidadas en la misma tabla, es probable que tengas una tabla mal estructurada ;-)

Answer 13

Ciertamente no es inusual. Sin embargo, al menos en Oracle, 7 es un número especial, ya que más que eso, y el optimizador ya no puede probar cada orden de unión (debido al crecimiento factorial en el número de posibilidades). Por lo tanto, sería prudente evitar pasar de 7 a menos que esté preparado para cuidar su plan de ejecución.

Answer 14

Creo que lo que quieres evitar es una profundidad de unión mayor que 7. 7 combinaciones internas de menos de 7 combinaciones en profundidad ciertamente no es desconocida, pero a veces las personas escuchan " 7 combinaciones " y piense que el no-no es 7 combinaciones, no profundidad.