¿Cual es la diferencia entre joins implícitos y explícitos?

Question

Más allá de conocer la diferencia entre los JOINS explícitos e implícitos quiero saber ¿cuáles son más eficientes y performantes?

Answer 1

¿Hay diferencia de rendimiento?

No. No hay ninguna diferencia de rendimiento entre un join implícito o explícito. Siempre y cuando se traten de consultas equivalentes, el motor de base de datos ejecutará las consultas de la misma manera. (Nota: por veces pueden ocurrir diferencias debido a un defecto en el motor de base de datos. Recuerdo que esto sucedió en algunas versiones antiguas de Oracle. Pero en realidad no era mas que eso: un defecto que eventualmente se corrigió)

Realmente, la única diferencia entre el join implícito o explícito es la sintaxis en sí.

¿Hay ventaja de usar una notación más bien que la otra?

Sí. Siempre es mejor usar joins explícitos.

Razones:

1. Porque ya por décadas se considera que la sintaxis de los joins implícitos está obsoleta.

En el estándar SQL-89, solo existía la notación implícita. Pero en 1992 (¡ya hace 25 años!), con el SQL-92, se introdujo la notación explícita. Desde entonces, es comúnmente aceptado que la norma debería ser de usar la nueva notación explícita, aunque en realidad, como ya ha pasado tanto tiempo, ya ni se puede considerar nueva.

2. Porque cuando la consulta es más compleja, es muy fácil equivocarse al definir las condiciones de join.

Para entender este segundo punto mejor, tomemos como ejemplo esta consulta con joins explícitos:

select a.colA, b.colB, c.colC
  from TableA a
  join TableB b on b.aid = a.id
  join TableC c on c.bid = b.id
 where a.colA like '%abc%'

... y comparémoslo a su equivalente usando joins implícitos:

select a.colA, b.colB, c.colC
  from TableA a, TableB b, TableC c
 where a.colA like '%abc%'
   and b.aid = a.id
   and c.bid = b.id

Aunque este ejemplo es bien sencillo, ya se puede apreciar que la notación de join explícito comunica muy bien cuáles son las condiciones que juntan las diferentes tablas. En contraste, con la notación implícita no es inmediatamente obvio de qué manera se relacionan las 3 tablas. Y cuanto más complejo es la consulta, menos claro y más confuso es.

Peor aún, con la notación implícita, sobre todo con consultas más complejas, es muy fácil que se nos olvide una condición de join, por ejemplo:

select a.colA, b.colB, c.colC
  from TableA a, TableB b, TableC c
 where a.colA like '%abc%'
   and b.aid = a.id

En esta consulta, por habernos olvidado de la condición c.bid = b.id, por accidente estamos creando un plan cartesiano con TableC.

En contraste, debido a la sintaxis del join explícito, es muy difícil cometer ese error, porque para cada join, estamos obligados a definir una claúsula ON, de lo contrario, la consulta no va a correr.

3. Porque es la única forma dentro del estándar SQL de definir un outer join (left o right join).

Nuevamente, si tomamos el ejemplo siguiente con join implícito:

select a.colA, b.colB, c.colC
  from TableA a, TableB b, TableC c
 where a.colA like '%abc%'
   and b.aid = a.id
   and c.bid = b.id

... pero ahora queremos que el join con TableC sea un left join en vez de un inner join. En varios motores de bases de datos, en ese caso, no hay forma de definirlo a menos que usemos la notación explícita. Y en casos donde sí existe una notación implícita para el motor de bases de datos, esa notación queda fuera del estándar SQL, y no te sirve un otros motores de bases de datos.

Por ejemplo, es cierto que Oracle te permite definir el left join de esta manera usando el (+):

select a.colA, b.colB, c.colC
  from TableA a, TableB b, TableC c
 where a.colA like '%abc%'
   and b.aid = a.id
   and c.bid (+) = b.id

... pero esta sintaxis solo funciona en Oracle. Y hasta en Oracle, se considera obsoleta. Además, es muy fácil equivocarse, sobre todo cuando la condición de join es poco más compleja.

En contraste, si observamos el left join usando la notación explícita:

select a.colA, b.colB, c.colC
  from TableA a
  join TableB b on b.aid = a.id
  left join TableC c on c.bid = b.id
 where a.colA like '%abc%'

... notamos que lo único que se necesita para que se le haga un left join con TableC es cambiar join a left join, asumiendo que partimos de la notación explícita. Es muy sencillo sin mayor riesgo de errores.