Saya memiliki kebutuhan yang sama, dan inilah cara saya mengatasi masalah pergerakan saham Anda (yang juga menjadi masalah saya).
Untuk memodelkan pergerakan stok (+/-), saya memiliki supplying dan order saya tabel. Pengadaan bertindak sebagai +stok saya, dan pesanan saya -stok saya.
Jika kita berhenti di sini, kita dapat menghitung stok kita yang sebenarnya yang akan ditranskripsikan ke dalam kueri SQL ini:
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
Yang akan memberikan sesuatu seperti:
id name stock
=========================
1 ASUS Vivobook 3
2 HP Spectre 10
3 ASUS Zenbook 0
...
Meskipun ini dapat menghemat satu tabel, Anda tidak akan dapat menskalakannya, oleh karena itu fakta bahwa sebagian besar pemodelan (imho) menggunakan stock perantara tabel, sebagian besar untuk masalah kinerja.
Salah satu kelemahannya adalah duplikasi data, karena Anda perlu menjalankan ulang kueri di atas untuk memperbarui stok Anda (lihat updatedAt kolom).
Sisi baiknya adalah kinerja klien. Anda akan memberikan respons yang lebih cepat melalui API Anda.
Saya pikir kerugian lain mungkin jika Anda mengelola toko dengan lalu lintas tinggi. Anda dapat membayangkan membuat tabel lain yang menyimpan fakta bahwa stok sedang dihitung ulang, dan membuat pengguna menunggu hingga penghitungan ulang selesai (permintaan push atau polling panjang) untuk memeriksa apakah setiap itemnya masih tersedia (stok>=permintaan pengguna). Tapi itu kesepakatan lain...
Bagaimanapun, bahkan jika kueri penghitungan ulang stok menggunakan subkueri anonim, itu seharusnya cukup cepat di sebagian besar toko yang relatif menengah.
Catatan
Anda lihat di product_order , saya menggandakan harga dan PPN. Ini untuk alasan keandalan:untuk membekukan harga pada saat pembelian, dan untuk dapat menghitung ulang total dengan banyak desimal (tanpa kehilangan sen di jalan).
Semoga membantu seseorang yang lewat.
Sunting
Dalam praktiknya, saya menggunakannya dengan Laravel , dan saya menggunakan perintah konsol , yang akan menghitung stok produk saya dalam batch (saya juga menggunakan parameter opsional untuk menghitung hanya untuk id produk tertentu), jadi stok saya selalu benar (relatif terhadap kueri di atas), dan saya tidak pernah memperbarui tabel stok secara manual.
