Cita:
Iniciado por yeyowave
tu estas haciendo la consulta solamente a las tablas avstock_cab y avstock_det, en ningun momento listas la tabla productos
No la listo porque esa tabla no contiene información de todos los productos, tal y como ya te lo aclaró quimfv.
Y en ese punto es donde estoy en total desacuerdo con tu diseño: Si PRODUCTOS es
tabla base (tabla de la que dependen otras, pero no depende de ninguna), y es a donde se referencias las FK de otras tablas, debe contener forzosamente
todos los productos, y si su ID es numérico, no puede contener ningún ID que sea cero.
Ahora bien, si aún así quieres usarla, te mostraré una curiosidad, usando tu propia consulta del primer post:
Código MySQL:
Ver original -> stc.id_prod,
-> pr.nombre,
-> -- stc.f_actualizado,
-> count(stod .id_prod
) esperan
-> INNER JOIN avstock_det stod
ON stc.id_prod
= stod.id_prod
+---------+---------------+---------+
| id_prod | nombre | esperan |
+---------+---------------+---------+
| 1641 | producto demo | 4 |
+---------+---------------+---------+
Como puedes ver, con tu propia consulta (la que posteas al principio), tampoco salen 6 unidades relacionadas con ese supuesto producto.
Nota: Tuve que comentar una de las columnas porque el campo mencionado no existe en tu descripción inicial, y por tanto no sé de qué tipo es.
Ahora bien, supongamos, tomando la aclaración de quimfv, que en lugar de poner el stock, ponemos las cosas como se debe, esto es, la tabla PRODUCTOS primero.
El resultado sería:
Código SQL:
Ver originalmysql> SELECT
-> stc.id_prod,
-> pr.nombre,
-> -- stc.f_actualizado,
-> COUNT(stod .id_prod) esperan
-> FROM productos pr
-> LEFT JOIN avstock_cab stc ON pr.id = stc.id_prod
-> INNER JOIN avstock_det stod ON stc.id_prod = stod.id_prod
-> GROUP BY stc.id_prod;
+---------+---------------+---------+
| id_prod | nombre | esperan |
+---------+---------------+---------+
| 1641 | producto demo | 4 |
+---------+---------------+---------+
1 ROW IN SET (0.00 sec)
Se pone
siempre primero la tabla PRODUCTOS en estos casos porque lo que se desea es un listado
de productos de los que se requiere cierta información (las solicitudes), y no al revés... ¿Se entiende la lógica de eso?
Ahora bien, como ese pseudoproducto no existe, no aparecerá en el listado, y eso pone en evidencia la inconsistencia de datos de la base: No puede existir una operación registrada para un producto que
no existe...
¿Se comprende?
Resumiendo:
1) La primera consulta que planteas (según los datos que aportas), devuelve tres unidades para el pseudoproducto.
2) La segunda consulta devuelve
tambien tres unidades para el pseudoproducto.
Sobre la base de estos
hechos, se puede afirmar que
el error no está en las consultas, sino en los datos que tienes en la base.
¿Te quedó claro ahora?
Revisa los datos, verifica las relaciones, define correctamente las FK, depura los datos "basura" (datos que no cumplen las restricciones), y vuelve a probar las consultas.