Tengo una consulta que tiene 7 uniones internas (porque mucha de la información se distribuye en otras tablas), algunos compañeros de trabajo se han sorprendido. Me preguntaba si deberían sorprenderse o si tener 7 combinaciones internas es normal.¿Son siete uniones internas en una consulta demasiado?
que no es desconocida, pero yo lo colocaría en una vista de la facilidad de uso y mantenimiento
Es normal si su esquema es en el 5th normal form:)
Dos preguntas:
Si es así, entonces siete está bien. Si no puede explicar la consulta, entonces el siete es demasiado.
Dependiendo de lo que esté tratando de lograr, una gran cantidad de uniones en una consulta no son notables.
Personalmente, me preocuparía menos el número de combinaciones empleadas para devolver un conjunto de resultados deseado y más preocupado por si la consulta está optimizada y ejecutándose dentro de parámetros aceptables.
Si la consulta está completamente optimizada y no se puede recortar, pero la consulta en sí misma no se ejecuta lo suficientemente rápido, es posible que el diseño de la estructura de datos no encaje con lo que intenta hacer. En ese momento puede volver a evaluar lo que está tratando de lograr o la estructura de los datos que está alimentando su modelo de negocio.
Probablemente no sea normal, pero ciertamente no es excesivo. Si te encuentras uniéndote a las mismas tablas una y otra vez, crea algunas vistas.
No es para nada inusual. Con un sistema como Siebel, es común ver recuentos de unión en cifras dobles.
Siete uniones lo hace más difícil para la legibilidad, pero más importante es el rendimiento y la escalabilidad. Si están bien, ve por ello.
número de combinaciones depende de su modelo de datos, 7 combinaciones pueden estar en su consulta si eso es lo que consulta - Recuerdo tener consultas similares en una aplicación en la que trabajé hace mucho tiempo, el rendimiento depende de muchos factores (tamaño de la tabla, índices, carga del servidor, configuración del servidor para nombrar algunos) y no creo que se pueda generalizar que las 7 uniones sean malas.
si funciona para usted, entonces supongo que está bien: D
Creo que lo que se quiere evitar es unirse a una profundidad mayor que se une a 7. 7 interna de menos de 7 se une a fondo luego, no es insólito de, pero a veces las personas escuchan "7 se une" y piensan que el no-no es 7 uniones, no profundidad.
¿Qué quiere decir "profundidad"? Supongo que es uniones paralelas, no uniones en serie. – dkretz
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 :)
Cerrar, es en realidad informix – seFausto
es esto 7 uniones internas en la misma mesa, 7 juntas internas en diferentes tablas, o 7 anidados uniones internas?
... pregunta truco! Realmente no importa, si eso es lo que requiere la estructura de su base de datos, entonces es correcto
advertencia: si se trata de 7 combinaciones internas anidadas en la misma tabla, es probable que tenga una tabla mal estructurada ;-)
Sí, es normal, pero realmente no es una gran idea desde el punto de vista del rendimiento. Dado que los planes de consulta se basan en estimados costos, hay una increase in the number of errors a medida que aumenta une (o cualquier otro operador, para el 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 caro debido a una subestimación de cardinalidad. Si se estima que el subárbol devuelve cero filas, muchos planes cuestan más o menos lo mismo y puede haber errores en la selección del plan como resultado. Por lo tanto, notará que la estimación es "alta" para este caso, y podrían producirse algunos errores. 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, estar desactivado por un factor de 2 (10 filas) no se considera demasiado. (Los errores pueden aumentar exponencialmente con el número de uniones).
Además, el optimizador intenta equilibrar el tiempo requerido para llegar a un plan en comparación con el ahorro potencial: no pasará todo el día tratando de encontrar el plan más óptimo. Cuantas más combinaciones, mayor es la cantidad de planes alternativos, algunos de los cuales pueden ser más óptimos de lo que el optimizador tiene tiempo de encontrar.
Sin duda no es inusual. Sin embargo, al menos en Oracle, 7 es un número especial, como mucho más que eso y el optimizador ya no puede probar cada orden de combinación (debido al crecimiento factorial en el número de posibilidades). Por lo tanto, sería aconsejable evitar pasar de 7 a menos que esté preparado para cuidar de su plan de ejecución.
7 o más no es para nada inusual en almacenes de datos donde una tabla de hechos podría tener fácilmente claves foráneas a una docena de dimensiones. En el escenario de almacenamiento 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 que la tabla de hechos se utilice 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 primaria (es decir, seleccione todo sobre un cliente), porque las claves externas normalmente o escaneos de índice.
Me gusta mucho la base de datos normalizada, pero llega un momento en el que digo "Necesito ver. AHORA". y luego ve y haz una. –
vistas deben morir junto con procs almacenados. los desencadenantes pueden permanecer sin embargo. – Shawn
@Shawn: los relvars virtuales ("vistas") facilitan la independencia de los datos. Hay algunas características de un DBMS más útil que esto. – Apocalisp