4 respuestas en este tema

[santiago14]

Buenas, tengo una duda
Quiero saber la diferencia entre:

Select * From tabla1 t1, tabla2 ts
Where t1.codigo = t2.codigo
....

y

Select * From tabla1 t1 LEFT JOIN tabla2 t2 ON t1.codigo = t2.codigo
Where ....

Puse LEFT JOIN pero podría ser RIGHT JOIN...

La primera es un producto cartesiano simple...
El segundo caso, ¿es mejor, peor o igual que el primero?
¿Hay ventajas de uno sobre el otro?
¿Alguno es mas eficiente que otro?

Gracias.

[egostar]

Pues no veo ninguna diferencia si vemos como se comporta la consulta.

Plan
PLAN JOIN (AL INDEX (RDB$PRIMARY1), CA INDEX (FK_CLIENTES))
Adapted Plan
PLAN JOIN (AL INDEX (INTEG_15), CA INDEX (FK_CLIENTES))

Plan
PLAN JOIN (AL INDEX (RDB$PRIMARY1), CA INDEX (FK_CLIENTES))
Adapted Plan
PLAN JOIN (AL INDEX (INTEG_15), CA INDEX (FK_CLIENTES))

Pero quien soy yo para decirlo, los que saben de bases de datos nos pueden ilustrar mucho más.

Saludos

[egostar]

Por otro lado si se usa RIGHT JOIN, la consulta pudiera ser más lenta

Plan
PLAN JOIN (CA NATURAL, AL INDEX (RDB$PRIMARY1))
Adapted Plan
PLAN JOIN (CA NATURAL, AL INDEX (INTEG_15))

Saludos

[Delphius]

Hola Santiago,
Hace no mucho hemos debatido sobre el tema. Te dejo el enlace. 

Uno de los principales puntos cuando uno está pensando en hacer encuentros, implícitos o no, es preguntarse sobre que vamos a hacer con los nulos. No es lo mismo hacer un LEFT o un RIGHT que un INNER o un OUTER. Como no es lo mismo que uno de los miembros tenga o no nulos.
En el siguiente artículo de CodeProyect se ilustra el porqué no son la misma cosa.

En cuanto a rendimiento, la regla general dice que los encuentros tienden a ser más rápidos ya que se aprovechan mejor de los índices (si los hay).
Un encuentro cartesiano de tu ejemplo puede o no ser equivalente a un JOIN explícito. Todo depende de una serie de factores: índices, diseño del interpretador que posea el motor, si hay nulos y cómo presentarlos (al inicio, al final ó ignorarlos). Por lo general los motores tratan de convertir los productos cartesianos como JOINS, aunque es posible que no todos cumplan la regla.

Saludos,

[Sergio]

Cambia muchísimo en la velocidad de la SQL, digamos que cuanto más "pensada" este la sentencia y en el select tengas la "tabla principal" filtrada por su indice primario y lo secundario en left joins, la cosa mejora pero muchisimo respecto de hacer un select from de las dos tablas y añadir un monton de "wheres" para seleccionar los registros.

Realmente, si el optimizador de planes de FireBird fuera perfecto, daría lo mismo, por eso en el ejemplo de delphius le sale igual el plan, pero en la vida real, la diferencia puede ser de 1000 veces más rápido una forma que la otra.

De hecho, si pones una tabla en el select y la otra en el left join, y pruebas luego a intercambiar las dos tablas de sitio, normalmente ya obtienes tiempos de respuesta muy diferentes, sobre todo cuando los filtros finales los va a elegir el usuario y un solo filtro "mal elegido" puede hacer que el plan deje de usar indices.