Ir al contenido


Foto

Joins implícitos o explícitos.


  • Por favor identifícate para responder
16 respuestas en este tema

Encuesta: Que nomenclatura de Join prefieres (7 miembros han emitido voto)

Que nomenclatura de Join prefieres

  1. Explícita (7 votos [100.00%])

    Porcentaje de voto: 100.00%

  2. Implícita (0 votos [0.00%])

    Porcentaje de voto: 0.00%

Votar Los invitados no pueden votar

#1 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 03 mayo 2013 - 08:10

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



  • 0

#2 TiammatMX

TiammatMX

    Advanced Member

  • Miembros
  • PipPipPip
  • 1.750 mensajes
  • LocationUniverso Curvo\Vía Láctea\Sistema Solar\Planeta Tierra\América\México\Ciudad de México\Xochimilco\San Gregorio Atlapulco\Home

Escrito 03 mayo 2013 - 08:16

...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.
  • 0

#3 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 03 mayo 2013 - 09:52

Vamos a hablar un poco de historia :D :D :D

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
  • 0

#4 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 03 mayo 2013 - 09:54

Vamos a hablar un poco de historia :D :D :D

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
  • 0

#5 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 03 mayo 2013 - 10:00


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.



  • 0

#6 enecumene

enecumene

    Webmaster

  • Administrador
  • 7.419 mensajes
  • LocationRepública Dominicana

Escrito 03 mayo 2013 - 10:24

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 :D :D
  • 0

#7 Fenareth

Fenareth

    Advanced Member

  • Administrador
  • 3.486 mensajes
  • LocationMexico City

Escrito 03 mayo 2013 - 10:55



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.


:shocked: :lipsrsealed:

:embarrassed: :embarrassed: :embarrassed: :embarrassed: :embarrassed: :embarrassed: :embarrassed:

: : : : : : : : : : : : :

Saludox ! :)
  • 0

#8 felipe

felipe

    Advanced Member

  • Administrador
  • 3.283 mensajes
  • LocationColombia

Escrito 04 mayo 2013 - 02:23

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


Saludos!
  • 0

#9 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 04 mayo 2013 - 05:30

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,
  • 0

#10 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 05 mayo 2013 - 09:01

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.
  • 0

#11 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 05 mayo 2013 - 01:33

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,
  • 0

#12 cadetill

cadetill

    Advanced Member

  • Moderadores
  • PipPipPip
  • 994 mensajes
  • LocationEspaña

Escrito 06 mayo 2013 - 01:29

Estoy (y sin que sirva de precedentes :p 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 :p

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.


  • 0

#13 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 06 mayo 2013 - 12:11

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,
  • 0

#14 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 06 mayo 2013 - 12:15

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

  • 0

#15 santiago14

santiago14

    Advanced Member

  • Miembros
  • PipPipPip
  • 334 mensajes
  • LocationCerrillos - Salta - Argentina

Escrito 28 julio 2013 - 05:50

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?  :cheesy: ¿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.
  • 0

#16 poliburro

poliburro

    Advanced Member

  • Administrador
  • 4.945 mensajes
  • LocationMéxico

Escrito 28 julio 2013 - 06:45

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. :p je. a eso me refería.
  • 0

#17 santiago14

santiago14

    Advanced Member

  • Miembros
  • PipPipPip
  • 334 mensajes
  • LocationCerrillos - Salta - Argentina

Escrito 29 julio 2013 - 10:25

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

Gracias una vez mas.
  • 0




IP.Board spam blocked by CleanTalk.