¿Cuál es la razón para usar la doble unión interna en esta declaración SQL?

10

Estoy mirando esta consulta SQL heredada. El bit que no puedo entender es por qué es interno unir la misma tabla dos veces en las mismas columnas. Estoy hablando de Table1 y Table1 unidos con el alias "Table1Alias",

SELECT DISTINCT othercolumns,
                Table1Alias.columna
FROM   maintable
       INNER JOIN secondarytable
               ON maintable.id1 = secondarytable.a_id1
       INNER JOIN table1
               ON secondarytable.id2 = table1.id3
       INNER JOIN table1 Table1Alias
               ON secondarytable.id2 = Table1Alias.id3
       INNER JOIN thirdtable
               ON table1.id4 = thirdtable.id5
       INNER JOIN fourthtable
               ON thirdtable.id6 = fourthtable.id7
       INNER JOIN fivetable
               ON thirdtable.id8 = fivetable.id9
       INNER JOIN sixthtable
               ON Table1Alias.columna = sixthtable.id10
       LEFT JOIN seventhtable
              ON thirdtable.id11 = seventhtable.id12
WHERE  LEFT(secondarytable.type123, 2) BETWEEN '01' AND '09'
       AND secondarytable.type456 = 'cate'
       AND table1.type = '0'
       AND Table1Alias.columna = 'conn'
sql-server Matemáticas
fuente
¿Para qué es una autounión? (en inglés)
philipxy

Respuestas:

27

Puede ser útil reescribir la consulta de esta manera, por lo que es obvio que las 2 combinaciones son diferentes , es decir, las combinaciones son de diferentes subconjuntos (de la misma tabla):

FROM   maintable 
       INNER JOIN secondarytable 
               ON maintable.id1 = secondarytable.a_id1 
       INNER JOIN table1 
               ON secondarytable.id2 = table1.id3 
              AND table1.type = '0' 
       INNER JOIN table1 Table1Alias 
               ON secondarytable.id2 = Table1Alias.id3 
              AND Table1Alias.columna = 'conn' 
       INNER JOIN
       ...
WHERE  LEFT(secondarytable.type123, 2) BETWEEN '01' AND '09' 
       AND secondarytable.type456 = 'cate'
ypercubeᵀᴹ
fuente
no es el DÓNDE que se aplicará DESPUÉS de las uniones, es decir, estaría de acuerdo si esas restricciones fueran parte de la declaración de unión, es decir, conectadas por un AND, pero el DONDE en toda la experiencia se aplica al resultado de la unión que filtra las filas de la tabla unida, sin influir en la unión real.
Frank Hopkins
3
@Darkwing Hasta donde yo sé, no importa dónde coloque las condiciones, ya que es el trabajo del optimizador de consultas elaborar el mejor plan de superación. Sin embargo, es mejor ponerlos al lado de las uniones, ya que los hace más legibles, pero es solo una opinión
Matemáticas
Incluso si sucediera DESPUÉS de unirse, los resultados de las uniones son diferentes al final. Y sí, las filas unidas generalmente se filtran antes de unirse, ya que mejora el rendimiento.
Gherman
1
También es equivalente a unirse con una subconsulta, por ejemplo INNER JOIN (SELECT * FROM table1 WHERE type = 0) table1. Eso podría hacer aún más obvio lo que está sucediendo.
Barmar
3
@ Matemáticas: si una condición está en la ONcláusula de una combinación o en la WHEREcláusula puede ser muy importante si la combinación es un OUTER JOIN. Si una condición falla en la ONcláusula, la fila primaria todavía se incluye (sin una fila externa coincidente); Si falla en la WHEREcláusula, la fila primaria se excluye del conjunto de resultados.
RDFozz
8

Al whereobservar la cláusula, la fila a la que apunta señala que table1la columna typees = '0' y la fila a la que apunta señala table1aliasla columna columnaa = 'conn'.

Tal vez hay varias filas table1para el mismo id3?

Scott Hodgin
fuente
2

Sin ver la estructura de la tabla, el enfoque podría ser utilizar un índice no cubriente más pequeño y luego unirse a la tabla en un índice de cobertura más grande para obtener el resto de filas para evitar una operación de 'Búsqueda de clave' y evitar modificar los índices existentes (o si no puede modificar los índices)

Allan S. Hansen
fuente
2

Siempre que una tabla aparece más de una vez en una combinación compleja, generalmente es porque hay una entidad que participa en más de una relación. Ese parece ser el caso aquí, a juzgar por la respuesta que dio @Ypercube.

Las entidades y las relaciones se entienden generalmente a través de la semántica de los datos y la conexión con el tema subyacente. Si su sistema heredado fue construido cuidadosamente, probablemente se preocuparon por analizar el tema y definir cuidadosamente cada uno de los elementos de datos. Incluso pueden haber construido un modelo de Entidad-Relación. Es posible que se haya perdido todo ese trabajo cuidadoso, y usted está atrapado reconstruyéndolo excavando en el pasado. Esto es un poco como la arqueología.

Con nombres de tabla como Tabla1, no tenemos ni idea de cómo funciona su tema. E incluso si los nombres fueran descriptivos, nuestra comprensión del tema de su sistema puede ser muy diferente de lo que se necesita en su caso. Depende de usted.

Walter Mitty
fuente