Buenas! hace poco cambié de servidor. Y con ello, de un Mysql 4 a 5.
Una de las sentencias antiguas ahora parece q deja bloqueada la consulta. No da error pero se queda pensando sin dar ningún resultado.
Vendría a ser esto:
SELECT tabla1.campo1, tabla1.campo2, tabla1.campo3, tabla2.campo1, tabla3.campo1
FROM tabla1, tabla2
LEFT JOIN tabla3 ON 'tabla3.campo_id'='tabla1.campo_id'
WHERE tabla1.campo_id = tabla2.campo_idLa cosa que antes funcionaba :\
SGDB? MySql?
En Sql Server puedes poner:
SELECT *
FROM tabla1 INNER JOIN
tabla2 ON tabla1.campo1 = tabla2.campo2 LEFT OUTER JOIN
tabla3 ON tabla1.campo1 = tabla3.campo3
Intenta adaptarlo
Es Mysql.
Al final lo he conseguido solucionar con algo parecido a lo que proponías:
SELECT *
FROM tabla1
left JOIN tabla3 ON (tabla1.campo_id = tabla3.campo_id)
right JOIN tabla2 ON (tabla1.campo_id=tabla2.campo_id)Gracias por la ayuda 
#7 para estar bien hecha se usa un LEFT JOIN. Si está es porque aportará mejor rendimento inmediato o a largo plazo en versiones futuras que no emulaciones con varias consultas que encima luego resultan confusas. Me he encontrado muchas de estas cosas en el trabajo y no es para nada comodo seguir codigo que luego resulta se podia hacer más entendible y optimizado con instrucciones/metodos nativos del framework/programario/componente que estés usando.
#8 Que sea más comodo, sí. Que sea más rápido, no.
Las dos sentencias hacen exactamente lo mismo. Si no me equivoco, lo que hace la máquina es traducir la sentencia SQL a álgebra relacional, que es lo que se ejecuta. Hay métodos y equivalencias establecidas para pasar de SQL <-> álgebra relacional por lo que en teoría pongas más o menos wheres, mientras el resultado sea el mismo, no tiene por qué variar el tiempo de la consulta.
De hecho, cuando estudié bases de datos en la carrera, no se hizo ninguna mención a la eficiencia de una sentencia u otra. En cambio, si se hizo mucho hincapié en saber traducir del lenguaje natural a álgebra relacional, ya que de éste pasabas fácilmente a la sentencia SQL que ejecutarías en tu servidor.
De hecho luego igual no se ejecuta ni esa consulta, igual se ejecuta otra que da el mismo resultado.
SQL es un lenguaje no procedural, dice que hacer pero no como hacerlo.
#9 si fuera asi todos los productos serian iguales, no obstante las empresas usan unos u otros productos por rendimiento, fiabilidad o lo que sea. Las estructuras de datos y rutinas que se ejecutan para unas u otras son totalmente diferentes para optimizar recursos. Cuando haces were's el interprete de SQL se espera cualquier otra sentencia anidada, esto influye tanto en tiempo de proceso como en memoria, en cambio si haces joins está mucho mas restringido por lo que las comprobaciones posteriores son mas ligeras tanto en memoria como en proceso.
Claro está que todo esto depende del fabricante de cada base de datos
#10 a eso me refiero Por ejemplo, el motor de MySQL, MyISAM emula ciertos comandos (o al menos en las versiones con las que trabajé hará 1 año o 2), pero Oracle usa rutinas diferentes incluso para diferentes tipos de joins.
#11 Pues parece que me equivocaba con lo del rendimiento. Pero para sorpresa mía, no en el sentido que yo creía.
Buscando benchmarks sobre consultas anidadas o con joins, encontré lo siguiente:
Por lo visto si hay diferencias de rendimiento, pero no a favor de los joins, sino de las consultas anidadas xDD
Míratelo, está curioso. Me intentaré poner en contacto con el profesor que me dio bases de datos a ver que opina del tema.
Esto así no te va? O era una Outer simple?
edit!
Shit, no habia visto tabla3! Soz... xD
#12 LOL asi da gusto discutir por aquí
PD: Cuando pueda me haré unas consultillas en oracle y subiré los resultados a ver que tal.
