Имам същата нужда и ето как се справих с проблема ви с движението на акциите (което стана и мой проблем).
За да моделирам движението на запасите (+/-), имам моя supplying и моята order маси. Снабдяването действа като моя +наличност, а моите поръчки - моите -наличност.
Ако спрем до това, бихме могли да изчислим действителните си запаси, които ще бъдат транскрибирани в тази 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
Което би дало нещо като:
id name stock
=========================
1 ASUS Vivobook 3
2 HP Spectre 10
3 ASUS Zenbook 0
...
Въпреки че това може да ви спести една таблица, няма да можете да мащабирате с нея, оттук и фактът, че по-голямата част от моделирането (imho) използва междинен stock таблица, най-вече за проблеми с производителността.
Един от недостатъците е дублирането на данни, защото ще трябва да изпълните отново заявката по-горе, за да актуализирате наличността си (вижте updatedAt колона).
Добрата страна е производителността на клиента. Ще предоставяте по-бързи отговори чрез вашия API.
Мисля, че друг недостатък може да бъде, ако управлявате магазин с голям трафик. Можете да си представите да създадете друга таблица, която съхранява факта, че наличност се преизчислява, и да накара потребителя да изчака, докато преизчисляването приключи (насочена заявка или дълга анкета), за да провери дали всеки от неговите/нейните артикули все още е наличен (наличност>=потребителско търсене). Но това е друга сделка...
Както и да е, дори ако заявката за преизчисление на запасите използва анонимни подзаявки, тя всъщност трябва да е достатъчно бърза в повечето от относително средните магазини.
Забележка
Виждате в product_order , дублирах цената и ДДС. Това е от съображения за надеждност:за замразяване на цената в момента на покупката и за възможност за преизчисляване на общата сума с много десетични знаци (без да губите цента по пътя).
Надявам се да помогне на някой минаващ.
Редактиране
На практика го използвам с Laravel , и използвам конзолна команда , който ще изчисли наличността на моя продукт в партида (използвам също и незадължителен параметър за изчисляване само за определен идентификатор на продукт), така че моята наличност винаги е правилна (спрямо заявката по-горе) и никога не актуализирам ръчно таблицата за наличности.
