Question

Buenas, lo que estoy queriendo hacer quizas se pueda hacer de otro modo pero por ahora es lo unico que se me ocurre:
Tengo una tabla pedidos, una tabla detallePedidos y una de articulos. En detallePedidos tengo el codigo del articulo y la cantidad a pedir, junto con un codigo de detalle y el codigo de pedido.
Lo que quiero hacer es agregar la cantidad del pedido al stock del articulo, pero mi problema está en que un pedido puede tener varios detallePedido y por ende, varios articulos distintos..
Cómo podría hacer para ir seleccionando de a uno e ir pasando el stock a la tabla articulos?
Ojalá me haya expresado bien y me puedan ayudar.
Desde ya, gracias ! :D

Comments

Por aclarar, lo que quieres es que en un campo de la tabla artículos, se sume o se reste, para cada artículo, el número de items comprados en un pedido?

---

Exactamente, eso mismo.

---

¿Y se suma o se resta?
Si se suma, quiere decir que ese campo indicará el nº de artículos que hay pedidos, y otro proceso se encargará de "comprar" esos artículos que hay que servir y volver a poner el contador a cero.
Si se resta, quiere decir que hay que comprobar previamente que hay stock suficiente para satisfacer el pedido, y si no, dar error.

---

Se suma, es el pedido que le hago al proveedor. Lo que intento hacer es la confirmacion de la recepcion del pedido realizado, una vez "llega" el pedido se repone el stock de los articulos (y se borra de la lista de pedidos "pendientes").
Lo que no sé cómo hacer es la reposicion del stock, siendo que en un pedido tengo varios articulos distintos.. Se entiende?

---

¿Y el proveedor siempre te sirve todo lo que le pidas? ¿O puede que te sirva menos? Porque en este caso tienes que elegir qué pedidos se completan, lo cual es un poco más complicado (a no ser que sea por orden de pedido)

---

Por el momento me "trae" todo. No es una web 100% funcional para el mercado, es un proyecto final para la facu y creo que esos detalles los puedo omitir, por lo menos por el momento..
Por ahora necesito que todos los articulos del pedido que se está confirmando, repongan su stock.

---

Hola @ShamiiCooper,

por tu descripción de las tablas, el almacenamiento está mal normalizado... lo que deriva en problemas como este.

Puede ser que por ser un proyecto final, puedas obviar y acortar varias cosas, pero así como lo describís, además de no poder hacer bien lo que te hace falta, si se actualiza el precio o la descripción de un artículo, se te van a cambiar los detalles de los pedidos anteriores!

Preguntá a tu profesor, pero yo no aprobaría un trabajo final con este defecto...

---

No debería porqué cambiarse los pedidos anteriores.. Acorté las tablas y los campos acá porque no lo creí necesario pasar todo.. Tengo una tabla artículos, y pedidos, ambas con sus tablas de detalle.
Sigue estando mal así? Cómo sería la correcta normalizacion?
Agradezco mucho su ayuda!

---

Sí se cambian. Decís que en detallePedido estás guardando un ID, una referencia al Pedido, la cantidad, el código del artículo.

Cuando quieras acceder vía el código del artículo para mostrar la descripción o cualquier otro dato del artículo que te haga falta, vas a acceder al contenido actual, no al que tenía al momento de ser realizado el pedido... se entiende?

PD: al no conocer el problema completo, no encuentro sentido a que la tabla de Articulos tenga una tabla de detalles. Para el Pedido, se sobreentiende el motivo.

---

Aaaaahh, entiendo, entiendo. El único dato que podría modificarse del articulo sería el precio (son libros, dudo mucho que cambie el autor, descripción o lo que sea), y en la tabla detalle de pedido (donde va el id del articulo) también tengo un campo con el precio, y en la tabla de pedidos tengo un campo total, donde voy sumando el precio total de cada detalle de pedido (cant*precio), para sacar el total del pedido. Ahí está bien?
Sinceramente, ahora que lo mencionas, yo tampoco le veo el sentido a la tabla detalle de artículos, debería modificar eso.

Answer 1

Hola @ShamiiCooper,

si tu software permite cambiar el autor, la descripción o lo que sea, tenés que asumir que ese dato va a ser cambiado en algún momento, ya sea porque se encontró un dato mal cargado o por malicia.
Un sistema no está bien hecho si funcionar bien depende de los datos que carguen las personas que lo usan.

De hecho, esto es una de las mayores inconsistencias de datos que permiten a los empleados robar dinero o mercaderías (tema para otro hilo de conversación).

Respecto de las tablas, te quedaría:

• la tabla de Articulos.
• la de Pedidos, pero sin el total. Tendrías una repetición de datos si guardás algo que puede ser calculado (con un simple SUM en este caso).
• detallePedidos, con ID, ID_Pedido, cantidad y todos los datos del Artículo que constan en el pedido real que estás modelando, como por ejemplo: descripción, precio, impuestos, etc.

Luego, pasemos a tu pregunta original: el stock, no se suma ni se agrega en ninguna parte, porque hacerlo viola la Normalización. La forma de calcular los egresos es hacer un SUM() sobre las tablas de detalles de los comprobantes de salida; los ingresos será un SUM() sobre las tablas de detalles de las entradas; el stock es la suma de lo ingresado menos la suma de lo egresado, que se calcula con un UNION sobre las tablas de los detalles, que serán isomórficas respecto de la cantidad y el código del artículo al menos.

Antiguamente, en el siglo pasado, como los RDBMS eran lentos y la potencia de cálculo poca, se violaba la Normalización en estos aspectos para hacer al software más veloz, pero se implementaba en esos términos: violando la 3ra FN para conseguir un resultado, y asumiendo la gran cantidad de código extra que esto implicaba.

Hoy, bien entrados en el siglo XXI, no hay ningún motivo para violar la normalización en estos ámbitos... aunque algún docente muy desactualizado proponga esta estrategia de almacenamiento ;-)

Saludos cordiales!