entre Desarrolladores

Recibe ayuda de expertos

Registrate y pregunta

Es gratis y fácil

Recibe respuestas

Respuestas, votos y comentarios

Vota y selecciona respuestas

Recibe puntos, vota y da la solución

Pregunta

1voto

Consulta sql

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

magarzon comentado Feb 10

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?

ShamiiCooper comentado Feb 10

Exactamente, eso mismo.

magarzon comentado Feb 10

¿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.

ShamiiCooper comentado Feb 10

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?

magarzon comentado Feb 10

¿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)

ShamiiCooper comentado Feb 10

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.

Leonardo-Tadei comentado Feb 10

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...

ShamiiCooper comentado Feb 13

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!

Leonardo-Tadei comentado Feb 13

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.

ShamiiCooper comentado Feb 13

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.

1 Respuesta

2votos

Leonardo-Tadei Puntos207780

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!

ShamiiCooper comentado Feb 13

Arregladas las tablas, muchas gracias por eso.
Ahora, no estaría entendiendo del todo lo que me comentas del stock.. Cuando agrego un nuevo articulo, se ingresa con el stock disponible, y por cada venta voy descontando la cantidad que se vende.. Luego, cuando la editorial me "trae" el pedido, debería sumar al stock disponible, la cantidad que pedí a cada libro correspondiente.

Leonardo-Tadei comentado Feb 13

Por nada Shamil.

Lo que te está faltando para que esto cierre, es un comprobante para el alta de stock.

De la forma en que lo estás planteando, nunca podrías saber cuántos libros ingresaron entre fechas o cuándo fue la última vez que te entró un libro determinado...

Mantené los Articulos como ahora, pero agregá una tabla Entregas y otra detalleEntregas con la misma estructura que los pedidos.

Luego, el stock se calcula nada más que con una query sobre las tablas de detalles. Esta es la forma correcta de implementar un sistema de stock, que además, refleja buenas prácticas administrativas, como el tener un comprobante que refleje cada movimiento relevante que se hace.

Saludos cordiales!

ShamiiCooper comentado Feb 13

Ahora voy entendiendo mucho mejor las cosas.. Igualmente te comento, en la tabla pedidos tengo un campo Recibido (tipo bit, que va en false) y dos fechas: la de pedido y la de recibido, que esta ultima va con valor null hasta que se recibe el pedido y se confirma (momento en el que debería sumar el stock, y colocar en true el campo Recibido), además del campo CodigoEditorial y el de NroPedido, obviamente. (El código de editorial va porque se le pide directamente a ésta, y no a un proveedor general).
En la tabla entregas/DetalleEntregas, irían los datos de los libros que realmente fueron recibidos, por el caso en que no haya alguno/s, verdad?
Muchas gracias por resolver mis dudas, y disculpa tanto cuestionario.
Saludos ! (:

Leonardo-Tadei comentado Feb 13

Sí, el planteo es ese.

El cálculo de existencias dependerá de si el pedido fue recibido y de más cosas que dependen de la lógica de negocio. Lo mismo para la mercadería entregada en dónde por ejemplo tenés que considerar una entrega cancelada porque se cargó mal.

Luego, las sumas y restas son sobre los detalles de los comprobantes que están consolidados.

Me alegro de que te haya servido la conversación!

Por favor, accede o regístrate para responder a esta pregunta.

¿Conoces alguien que puede responder?
¡Comparte esta pregunta!


Actividad Reciente

¿Eres Usuario Apple?

...

Bienvenido a entre Desarrolladores, donde puedes realizar preguntas y recibir respuestas de otros miembros de la comunidad.

Conecta