Jeg har det samme behov, og her er, hvordan jeg tacklede dit aktiebevægelsesproblem (som også blev mit problem).
For at modellere lagerbevægelser (+/-), har jeg min forsyning og min ordre tabeller. Levering fungerer som mit +lager, og mine ordrer er mit lager.
Hvis vi stopper med dette, kunne vi beregne vores faktiske lager, som ville blive transskriberet til denne SQL-forespørgsel:
SELECT id, name, sup.length - ord.length AS 'stock'FROM product# Beregner antallet af ankomne varerINNER JOIN ( SELECT productId, SUM(quantity) SOM 'længde' FRA levering, HVOR ankom ER TRUE GROUP BY productId) AS sup ON sup.productId =product.id# Beregner antallet af ordreINNER JOIN ( SELECT productId, SUM(quantity) AS 'længde' FRA product_order GROUP BY productId) AS ord ON ord.productId =product.id
Hvilket ville give noget som:
id name stock==========================1 ASUS Vivobook 3 2 HP Spectre 10 3 ASUS Zenbook 0 ...
Selvom dette kan spare dig for én tabel, vil du ikke være i stand til at skalere med den, derfor det faktum, at det meste af modelleringen (imho) bruger en mellemliggende aktie tabel, mest af hensyn til ydeevnen.
En af ulemperne er dataduplikeringen, fordi du bliver nødt til at køre forespørgslen ovenfor igen for at opdatere dit lager (se updatedAt kolonne).
Den gode side er klientens ydeevne. Du vil levere hurtigere svar gennem din API.
Jeg tror, at en anden ulempe kunne være, hvis du administrerer en butik med stor trafik. Du kunne forestille dig at oprette en anden tabel, der gemmer det faktum, at et lager bliver genberegnet, og få brugeren til at vente, indtil genberegningen er færdig (push-anmodning eller lang polling) for at kontrollere, om hver af hans/hendes varer stadig er tilgængelige (lager>=brugerefterspørgsel). Men det er en anden aftale...
I hvert fald, selvom forespørgslen om lagerberegning bruger anonyme underforespørgsler, burde den faktisk være ret hurtig nok i de fleste af de relativt mellemstore butikker.
Bemærk
Du kan se i product_order , jeg duplikerede prisen og momsen. Dette er af pålidelighedsgrunde:for at fryse prisen i købsøjeblikket og for at kunne genberegne totalen med mange decimaler (uden at miste øre i vejen).
Håber det hjælper nogen der går forbi.
Rediger
I praksis bruger jeg det med Laravel
, og jeg bruger en konsolkommando
, som vil beregne mit produktlager i batch (jeg bruger også en valgfri parameter til kun at beregne for et bestemt produkt-id), så mit lager er altid korrekt (i forhold til forespørgslen ovenfor), og jeg opdaterer aldrig lagertabellen manuelt.