16 replies to this topic

[poliburro]

A partir de un artículo que he redactado sobre MySql, me pareció interesante saber que tipo de nomenclatura usan para sus Joins: Implícita o Explicita y dado el caso cuál prefieren.

Notación implícita:

SELECT Campos
FROM   empleado, departamento
WHERE  empleado.IDDepartamento = departamento.IDDepartamento

notación explícita:

   SELECT Campos
      FROM   empleado
inner join departamento
          on empleado.IDDepartamento = departamento.IDDepartamento

[TiammatMX]

...notación explícita:

   SELECT Campos

      FROM   empleado

inner join departamento

          on empleado.IDDepartamento = departamento.IDDepartamento

Ciertamente, evitas errores y "malos entendidos". Podría ser más código, pero al final es más entendible y más rápido de lo que la implícita podrá dar.

Aunque depende muchas veces de la complejidad de la consulta.

[egostar]

Vamos a hablar un poco de historia

Cuando inicié a usar los famosísimos Queries por allá de 1997, utilizaba la forma implicita, pero hoy sin lugar a dudas uso la forma explicita,

Saludos

[poliburro]

Vamos a hablar un poco de historia

Cuando inicié a usar los famosísimos Queries por allá de 1997, utilizaba la forma implicita, pero hoy sin lugar a dudas uso la forma explicita,

Saludos

¿Creeras que su uso aún es muy extendido? yo estoy casado con la nomenclatura explicita pero me sigo encontrando la implícita muy a menudo

[poliburro]

Ciertamente, evitas errores y "malos entendidos". Podría ser más código, pero al final es más entendible y más rápido de lo que la implícita podrá dar.

Cierto aunque depende mucho del que codifica, Me he encontrado con sentencias así:

SELECT e.campo1, e.campodos, y.campo1 FROM   empleado e  INNER JOIN departamento y ON e.IDDepartamento = y.IDDepartamento

eso multiplicado por 10 tablas en joinsEncontrarte con eso en serio provoca que te quieras arrancar los ojos.

[enecumene]

Pues debiste incluir en la encuesta Implícita Corta o Larga y explícita Corta o Larga, debo admitir que uso la esplícita corta

[Fenareth]

Ciertamente, evitas errores y "malos entendidos". Podría ser más código, pero al final es más entendible y más rápido de lo que la implícita podrá dar.

Cierto aunque depende mucho del que codifica, Me he encontrado con sentencias así:

SELECT e.campo1, e.campodos, y.campo1 FROM   empleado e  INNER JOIN departamento y ON e.IDDepartamento = y.IDDepartamento

eso multiplicado por 10 tablas en joinsEncontrarte con eso en serio provoca que te quieras arrancar los ojos.

Saludox !

[felipe]

Les faltó repasar los pro y los contra. ¿que hay del rendimiento?


Saludos!

[Delphius]

Hola,
Dependiendo del motor y de si hay o no índices (sobre todo) cuando uno hace un "encuentro" implícito puede que en realidad no se obtenga el mismo resultado que el si efectivamente se hubiera hecho con la cláusula JOIN.

A lo que voy es que no necesariamente serán equivalentes... Es más, si se obtienen resultados idénticos es pura casualidad dada por ciertas particularidades que hacen al diseño y la consistencia de la información almacenada. Siempre y cuando se pueda garantizar de que los registros estén adecuamente normalizados y consistentes el resultado podrá ser igual en un encuentro explícito que en un implícito. Pero en lo general no.

Una consulta where con evaluación como IDTabla1 = IDTabla2 puede llevar a un producto cartesiano al cual luego se le aplica el "filtro" en el que pueden dar origen a nulos. Por su parte JOIN efectivamente está preparado para combatir y tratar los nulos adecuamente y no necesita ir a un producto cartesiano.

Saludos,

[egostar]

Así es, la gran diferencia entre implícito y explícito es que mientras en el implícito hace un INNER JOIN el explicito tiene las opciones de obtener más y mejor información, es decir, al utilizar LEFT, RIGHT, OUTER las consultas cambian enormemente con relación al INNER JOIN.

Saludos.

[Delphius]

En realidad amigo una consulta que tiene un WHERE IDTabla1 = IDTabla2 para generar el conjunto de datos resultante si no es capaz de trabajar con los índices, y no cuenta con un analizador bien aceitado, deberá hacer (y lo hacen) un producto cartesiano, o "todos vs todos" y luego aplicar el filtro correspondiente a la evaluación.
Los JOINs justamente se han pensado para no generar esta carga pesada y ofrecer un medio natural, y congruente al álgebra relacional y a la teoría de conjunto misma, si tener que hacer dobles vueltas sobre el conjunto original.

Repito, que no por hacer un WHERE IDTabla1 = IDTabla2 vamos a tener un JOIN implícito. Parecerá a nuestra vista que es un JOIN pero que en realidad no lo es. Aunque hay motores que a la consultas con ese "JOIN implícito" la alteran internamente para que sea realmente un JOIN, pero es de mucha importancia recalcar que NO TODOS LOS MOTORES HACEN ESTO... No al menos en las primeras versiones. 

Y lo digo por conocimiento de causa. En mi trabajo como DBA estaba acostumbrado a hacer SQL con encuentros implícitos en MS SQL Server (aunque no recuerdo cual versión) y obtenía algunos resultados que me llamaban la atención por la cantidad. Cuando le pedía que hiciera un JOIN me quedaba en claro: había diferencias en la cantidad de registros devueltos y eso me delató de que NO SON LO MISMO.

LEFT, RIGHT, OUTER son casos especiales de encuentro. Éstos permiten determinar como tratar el conjunto de cada miembro y en especial en que hacer con los nulos cuando aparecen. Esto de los nulos es otro de los aspectos claves que hay que considerar cuando se va a utilizar encuentros. Una operación WHERE IDTabla1 = IDTabla2 puede derivar a que se trate de una forma diferente a los nulos que si se emplea un JOIN. A su vez cada motor decide que hacer con esto y en que orden presentarlos.
Firebird por ejemplo ha variado desde 1.5 a 2.x en como presentar los nulos en una ordenación, explícita e implícita. Por ello incorporó la posibilidad de indicar NULL FIRST y/o NULL LAST.
Ejecútese en diferentes motores consultas con LEFT y/o RIGHT sobre tablas que tengas campos en nulos en sus IDs y observen como los ordenan... 

Las diferencias que tu señalas amigo no necesariamente son como táles. El que existe esas extensiones al JOIN no los hace diferentes.

Repito e insisto: ni son equivalentes, ni son iguales, ni son diferentes... todo dependerá de las consistencias que tengamos en nuestras tablas, del motor elegido (y cuanto inteligente sea). Lo cierto es que cada una está pensada para sus cosas. Y si se obtienen diferencias o semejanzas... ¡son producto de casualidad!

Saludos,

[cadetill]

Estoy (y sin que sirva de precedentes jejeje) totalmente de acuerdo con Delphius. Hay que evitar en la medida de lo posible los joins implícitos. Las razones leer los mensajes de Delphius, que sería repetir lo mismo

Yo también sigo viendo joins implícitos y, cuando los veo, intento explicar los motivos por los cuales no hacerlos. Lo malo es que sudan de mi cara y siguen a los suyo

Otra cosa que también me he encontrado es que hay gente que aprovecha en join para poner filtros a esa tabla, es decir, hacen cosas como

select * 
from tabla1 t1 
  join tabla2 t2 on t2.id = t1.id and t2.uncampo = 5
where otras condiciones

Y digo yo, cada cosa para lo que está pensado, no? La join para la relación entre tablas y el where para el filtro a aplicar a cada una de ellas.

[Delphius]

Otra cosa que también me he encontrado es que hay gente que aprovecha en join para poner filtros a esa tabla, es decir, hacen cosas como

select * 

from tabla1 t1 

  join tabla2 t2 on t2.id = t1.id and t2.uncampo = 5

where otras condiciones

Y digo yo, cada cosa para lo que está pensado, no? La join para la relación entre tablas y el where para el filtro a aplicar a cada una de ellas.

Exactamente, el where está pensando para hacer las evaluaciones. Aunque aquí cabría hacer un paréntesis... Es legal este tipo de encuentro:

SELECT *

FROM TABLA_A INNER JOIN TABLA_B ON  TABLA_A.ID < TABLA_B.ID

A éstos encuentros que se basan en evaluaciones dentro de un joins se los denomina theta-join. Cuando se emplea la igualdad, un caso especial de theta-joins, se le llama equi-join.

Ahora bien, si la idea es elaborar una consulta con evaluaciones complejas lo más lógico es que se se las coloque en el WHERE.

Saludos,

[poliburro]

De hecho, si evaluan el plan de ejecución de lo siguiente encontrarán que el rendimiento es exactamente el mismo:

   Select *
     from TablaA
left join TablaB
       on TablaA.Clave = TablaB.Clave
Where TablaA.CampoA >  10

    Select *
      from TablaA
inner join TablaB
        on TablaA.Clave = TablaB.Clave and
           TablaA.CampoA >  10

[santiago14]

Cierto aunque depende mucho del que codifica, Me he encontrado con sentencias así:

SELECT e.campo1, e.campodos, y.campo1 FROM   empleado e  INNER JOIN departamento y ON e.IDDepartamento = y.IDDepartamento

eso multiplicado por 10 tablas en joins. Encontrarte con eso en serio provoca que te quieras arrancar los ojos.

Si no entiendo mal, ese Select mostraría algunos campos de "empleado" y algunos de "departamento". ¿Por qué razón te arrancarías los ojos?  ¿Tan mal está eso? ¿Hay una mejor forma de hacer lo mismo y salvar los preciados órganos de la visión?
Perdón por mi ignorancia pero, este debate está bien interesante y nada mejor que aprender algo nuevo cada día...

Saludos.

[poliburro]

Perdón por mi ignorancia pero, este debate está bien interesante y nada mejor que aprender algo nuevo cada día...
Saludos.

No te preocupes amigo, toda participación es bienvenida. El problema no está en el resultado de la consulta amigo, el problema está en la identación del código. Citándome:

SELECT e.campo1, e.campodos, y.campo1 FROM   empleado e  INNER JOIN departamento y ON e.IDDepartamento = y.IDDepartamento

eso multiplicado por 10 tablas en joins. Encontrarte con eso en serio provoca que te quieras arrancar los ojos.

Imagina por un momento que tienes una consulta que involucra diez tablas, y a cada tabla en lugar de ponerle un alias distintivo, les colocan alias como  "a", "b", "c", tienes un total de diez alias en letra luego cuando lees el listado de campos encuentras algo como esto: a.campo, b.campo, c.campo, d.campo. y añade que en lugar de ordernar su código identándolo adecuadamente lo escriben de corrido. Esa consulta será muy dkificil de leer provocando un sentimiento de verdadero enojo contra quien la haya escrito. je. a eso me refería.

[santiago14]

Entendido y coincido. Siempre es bueno que seamos mas "gráficos" con nuestros alias.

Gracias una vez mas.