J'ai le même besoin, et voici comment j'ai résolu votre problème de mouvement de stock (qui est devenu mon problème aussi).
Afin de modéliser les mouvements de stock (+/-), j'ai mon supplying et ma order les tables. L'approvisionnement est mon +stock, et mes commandes mon -stock.
Si on s'arrêtait là, on pourrait calculer notre stock réel qui serait retranscrit dans cette requête 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
Ce qui donnerait quelque chose comme :
id name stock
=========================
1 ASUS Vivobook 3
2 HP Spectre 10
3 ASUS Zenbook 0
...
Bien que cela puisse vous faire économiser une table, vous ne pourrez pas évoluer avec, d'où le fait que la plupart des modélisations (à mon humble avis) utilisent un stock intermédiaire table, principalement pour des problèmes de performances.
L'un des inconvénients est la duplication des données, car vous devrez réexécuter la requête ci-dessus pour mettre à jour votre stock (voir le updatedAt colonne).
Le bon côté est la performance du client. Vous fournirez des réponses plus rapides grâce à votre API.
Je pense qu'un autre inconvénient pourrait être si vous gérez un magasin à fort trafic. On pourrait imaginer créer une autre table qui stocke le fait qu'un stock est en train d'être recalculé, et faire attendre l'utilisateur que le recalcul soit terminé (requête push ou scrutation longue) afin de vérifier si chacun de ses articles est encore disponible (stock>=demande des utilisateurs). Mais c'est une autre affaire...
Quoi qu'il en soit, même si la requête de recalcul des stocks utilise des sous-requêtes anonymes, elle devrait en fait être assez rapide dans la plupart des magasins relativement moyens.
Remarque
Vous voyez dans le product_order , j'ai dupliqué le prix et la TVA. Ceci pour des raisons de fiabilité :pour figer le prix au moment de l'achat, et pour pouvoir recalculer le total avec beaucoup de décimales (sans perdre de centimes au passage).
J'espère que cela aidera quelqu'un qui passe par là.
Modifier
En pratique, je l'utilise avec Laravel , et j'utilise une commande console , qui calculera mon stock de produits par lots (j'utilise également un paramètre facultatif pour calculer uniquement pour un certain identifiant de produit), donc mon stock est toujours correct (par rapport à la requête ci-dessus), et je ne mets jamais à jour manuellement la table de stock.
