Tengo la misma necesidad, y así es como abordé su problema de movimiento de existencias (que también se convirtió en mi problema).
Para modelar el movimiento de existencias (+/-), tengo mi supplying y mi order mesas. El suministro actúa como mi +stock y mis pedidos como mi -stock.
Si nos detenemos en esto, podríamos calcular nuestro stock real, que se transcribiría en esta consulta SQL:
SELECT
id,
name,
sup.length - ord.length AS 'stock'
FROM
product
# Computes the number of items arrived
INNER JOIN (
SELECT
productId,
SUM(quantity) AS 'length'
FROM
supplying
WHERE
arrived IS TRUE
GROUP BY
productId
) AS sup ON sup.productId = product.id
# Computes the number of order
INNER JOIN (
SELECT
productId,
SUM(quantity) AS 'length'
FROM
product_order
GROUP BY
productId
) AS ord ON ord.productId = product.id
Lo que daría algo como:
id name stock
=========================
1 ASUS Vivobook 3
2 HP Spectre 10
3 ASUS Zenbook 0
...
Si bien esto podría ahorrarle una tabla, no podrá escalar con ella, de ahí el hecho de que la mayoría de los modelos (en mi humilde opinión) utilizan un stock intermedio tabla, principalmente por problemas de rendimiento.
Una de las desventajas es la duplicación de datos, ya que deberá volver a ejecutar la consulta anterior para actualizar su stock (consulte el updatedAt columna).
El lado bueno es el rendimiento del cliente. Ofrecerá respuestas más rápidas a través de su API.
Creo que otra desventaja podría ser si está administrando una tienda de alto tráfico. Podría imaginarse crear otra tabla que almacene el hecho de que se está recalculando un stock y hacer que el usuario espere hasta que finalice el recálculo (solicitud de inserción o sondeo largo) para comprobar si cada uno de sus artículos todavía está disponible (stock>=demanda del usuario). Pero ese es otro trato...
De todos modos, incluso si la consulta de recálculo de existencias utiliza subconsultas anónimas, en realidad debería ser lo suficientemente rápido en la mayoría de las tiendas relativamente medianas.
Nota
Lo ves en el product_order , dupliqué el precio y el iva. Esto es por razones de confiabilidad:para congelar el precio al momento de la compra, y poder recalcular el total con muchos decimales (sin perder centavos en el camino).
Espero que ayude a alguien que pasa.
Editar
En la práctica, lo uso con Laravel , y uso un comando de consola , que calculará el stock de mi producto por lotes (también uso un parámetro opcional para calcular solo para una identificación de producto determinada), por lo que mi stock siempre es correcto (en relación con la consulta anterior) y nunca actualizo manualmente la tabla de stock.
