Registros diferentes de dos tablas
February 18, 08 by TomcaskPues si!! no me acordaba de como hacer una join en condiciones....
-
SELECT tabla1.id, tabla2.id
-
FROM tabla1 LEFT JOIN tabla2 ON tabla1.id = tabla2.id
-
WHERE tabla2.id IS NULL
Mediante la clausula "LEFT Join" fuerzas a listar todos los registros de la tabla 1 y con el "is
null" del "where" los filtras mostrando sólo los que no tengan su correspondiente id en la tabla 2.




















Robert Says: 19.02.08 at 10:42 am
Creo recordar que un inner join obligaba a que estuviera en las dos tablas y un right join o un left join variaba el modo en funcion de “la tabla de la izquiera o de la derecha” jejejej
Tomcask Says: 19.02.08 at 10:51 am
eso mismo señor le veo atento, lento pero atento. ji ji
Robert Says: 20.02.08 at 1:17 am
No se meta con los comentaristas que se quedará solo….
A los fieles seguidores hay que cuidarlos y mimarlos… o ¿cómo se piensa hacer rico?
Tomcask Says: 20.02.08 at 1:21 am
Dios me libre pero bueno solo tengo que llamarle por teléfono y ya ta….
Es mas formalmente invito a las cervezas que quieran los seguidores de este blog que hayan hecho mínimo un comentario hasta ahora.
No vale ahora apuntarse, lo siento ya habrá mas ofertas tranquilos…
Luis Says: 17.03.08 at 6:25 am
Buenas,
yo he utilizado este tipo de consulta y a medida que aumentan los registros aumenta el coste, demasiado… al final la sustituí por algo como:
select noticias.id
from noticias
where noticias.id NOT IN (select DISTINCT etiquetas_noticias.id_noticia from etiquetas_noticias)
Reduje el tiempo de ejecución de algo más de 6′ a 1′30”… así que, de todas formas, habrá que seguir optimizando… :)
Tomcask Says: 17.03.08 at 6:31 am
Gracias Luis por tu aportación, siempre había creído que los [IN, NOT IN] penalizaban mucho las querys.
Puede ser que tuvieras creados indices en especial para estas consultas?
Luis Says: 17.03.08 at 10:04 am
Ups…
No, no tengo índice especial, pero si lo hubiese tenido quizás no hubiese ido tan lenta la primera consulta… En mi caso, el problema es que por cada noticia, la base de datos busca en todos los registros de etiquetas_noticias por id_noticia… si hubiese tenido índice…
[5 minutos después]
He creado el índice y la consulta ha bajado a 56 segundos :)
Esto se llama ayudarse mutuamente… Gracias por iluminarme.
Tomcask Says: 17.03.08 at 10:08 am
Estupendo Luis !!!!
Por cierto porque no pruebas a hacer la query con la inner join tal como comento en el post, lo mismo nos sorprendemos mas todavia, no las tengo todas conmigo que un [IN] ofrezca mejor rendimiento que una join.
Y gracias a ti por aguantarme….
Luis Says: 18.03.08 at 1:12 am
Tarda lo mismo, pero si lo piensas, es lógico.
Tomcask Says: 18.03.08 at 1:45 am
Si Si, lógico es porque básicamente la left join hace lo mismo que el distinct de la consulta múltiple, pero tenia entendido que una join tendría mas rendimiento que subconsultas con operadores como in.