在庫管理データベースの設計

私にも同じニーズがあります。これがあなたの株の動きの問題にどのように取り組んだかです（これも私の問題になりました）。

在庫移動（+/-）をモデル化するために、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
    ...

これにより1つのテーブルを節約できますが、それを使用してスケーリングすることはできません。したがって、ほとんどのモデル化（imho）は中間のstockを使用します。表、主にパフォーマンスの問題のため。

欠点の1つは、データの重複です。これは、株式を更新するために上記のクエリを再実行する必要があるためです（updatedAtを参照）。列）。

良い面はクライアントのパフォーマンスです。 APIを介してより高速な応答を提供します。

トラフィックの多い店舗を管理している場合、もう1つの欠点が考えられます。在庫が再計算されているという事実を格納する別のテーブルを作成し、再計算が完了するまでユーザーを待機させて（プッシュ要求または長時間のポーリング）、すべてのアイテムがまだ利用可能かどうかを確認することを想像できます（在庫> =ユーザーの要求）。しかし、それは別の取引です...

とにかく、株式再計算クエリが匿名のサブクエリを使用している場合でも、実際には、比較的中規模の店舗のほとんどで十分に高速である必要があります。

注

product_orderに表示されます、価格と付加価値税を複製しました。これは信頼性の理由によるものです。購入時に価格を凍結し、多くの小数で合計を再計算できるようにするためです（途中でセントを失うことはありません）。

通りすがりの人の助けになることを願っています。

編集

実際には、Laravel で使用しています。、そして私はコンソールコマンドを使用しています、これはバッチで製品在庫を計算します（特定の製品IDについてのみ計算するためにオプションのパラメーターも使用します）ので、在庫は常に正しく（上記のクエリに対して）、在庫テーブルを手動で更新することはありません。