Cita:
Iniciado por alemaxxx Ok xD a ver si me entienden; la cuestión es que cuando voy a grabar la factura yo me voy a traer el id_fv --> id de la factura que lo meto en la variable $id_fv, va a tener un valor numérico, ahora mi pregunta es necesariopara tener todos los datos de esa factura usar el Where así:
y luego para saber el valor de los campos de las diferentes tablas lo llamo
Eso quería saber xD, a ver si así me pueden ayudar
SI preguntas si para traer todo el detalle de una factura, debes hacer un JOIN entre la cabecera de la factura con su detalle, la respuestas es SI. Es el modo.
Ahora bien si la pregunta es si debes hacer ESA consulta en base a TU modelo de datos... la respuesta es NO, por dos razones:
1) El modelo de datos está mal creado para el caso.
2) No puedes poner en una misma tabla el detalle de reparaciones junto con los insumos d euna reparación. Es irreal, porque la relación puede no ser 1:N sino 0:N, lo que forzosamente requiere un planteo completamente distinto.
Lo explico de esta forma:
Si toda reparación implica un único insmo de repuestos, el INNER JOIN te funcionará bien. Pero si algunas tienen cero insumos, entonces con un INNER JOIN no obtendrías el item reparado en la factura... porque no existen insumos.
Esa sería una situación de relación opcional, no mandatoria, y la consulta requiere LEFT JOIN, no INNER JOIN, con control de nulos.
Por otro lado, si un mismo item facturado requiere N insumos de repuesto, entonces tanto el item facturado como la reparación se repetirá N veces, una por cada item de repuestos necesario.
Ese caso sería un INNER JOIN, pero generaría errores de calculo.
Ahora bien, ¿cómo se soluciona ese? Pues sigue siendo un INNER JOIN, pero agrupado y con ROLLUP, o bien lo implementas en forma parcial entre SQL y programación (nota: NO postees código de programación en este foro, esos temas tienen su propio foro).
Eso, o bien haces lo que se suele hacer: Dos consultas diferentes: una para el detalle de las reparaciones y otra para los insumos facturados, ambas combinadas con un UNION.
Lo que en este último contexto está mal es el esquema de datos, y la forma en que construyes la consulta, porque los repuestos son parte de los items de la factura.
El tema no es sencillo, desde ya, y puede requerir más tablas para poder hacer una aplicación correctamente diseñada, optimizable y eficiente.