Registros diferentes de dos tablas
Pues si!! no me acordaba de como hacer una join en condiciones....
SQL:
-
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.
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
eso mismo señor le veo atento, lento pero atento. ji ji
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?
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…
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… :)
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?
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.
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….
Tarda lo mismo, pero si lo piensas, es lógico.
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.