usar inner join en mysql

[contactoenlacevisual]

hola amigos, es primera vez que uso inner join en una consulta sql, pasa que tengo una tabla productos y otras 4 que son marca, fabricante, stock, categoria.

cuando usaba where para cruzary mostrar las tablas me funcionaba bien pero cuando no ingresaba por ejemplo la marca el productos no lo muestra ya que usaba WHERE.

ahora vi para mi caso que se usa INNER JOIN pero cuando aplico esta consulta no me devuelve nada, cual sera e problema:

Código SQL:

SELECT * FROM productos pro
 INNER JOIN pr_categoria cat ON pro.id_categoria=cat.id 
INNER JOIN pr_fabricante fa ON pro.id_fabricante=fa.id 
INNER JOIN pr_marca ma ON pro.id_marca=ma.id
 INNER JOIN pr_stock st ON pro.id=st.id_padre 
WHERE pro.id=12
 

el codigo 12 existe en la db.

gracias

[gnzsoloyo]

El INNER JOIN es mandatorio, todas las condiciones deben cumplirse al mismo tiempo.
En tu caso al menos una de las relaciones en una de las tablas no se cumple.
Revisa los datos de las tablas. Ese producto tiene relaciones incompletas.

[contactoenlacevisual]

ok gracias, al usar where que diferencia hay?.

[gnzsoloyo]

Mucha, y las hemos explicado numerosas veces en el foro de MySQL, así como puedes encontrarla en los manuales de referencia:
- Por empezar un JOIN implícito (la coma) intenta unir los campos del mismo nombre, lo que puede dar resultados erróneos si los campos se llaman igual pero pertenecen a diferentes dominios.
- Si no hay campos de igual nombre, el resultado es un producto cartesiano, que es la pero forma de consulta posible. Ese producto cartesiano se ejecuta antes de aplicar el WHERE, por lo que el impacto en la performance puede ser catastrófico.
- El WHERE no es optimizable por el parser en MySQL, a diferencia de otros DBMS. Esto puede traer muchos problemas en la las consultas con tablas de grandes cantidades de registros.
- A diferencia del JOIN implícito, el INNER JOIN es optimizable por el parser, eligiendo la mejor forma de consulta.
- La selección de registros en el INNER JOIN no lee todos los registros que existen, sino los que cumplen con el ON a medida que se van leyendo, descartando sin cargar el restro.
- Si se usan condiciones en el ON sobre claves foráneas, eso mejora dado que se accede directamente al indice creado al generar una FK. Esto no sucede en el WHERE.
- Si los datos que se piden en el SELECT son solo los del indice, entonces ni siquiera se lee la tabla, sino que se toman del indice, con un mejor tiempo.

Todo esto es solo una parte de las razones, pero creo que te alcanzará.

Volviendo a tu problema, es altamente probable que al menos en UNA de las tablas no haya registros que cumplan las relaciones indicadas.

¿Lo verificaste?