[英]Stock management database design
我正在為我的公司創建一個 Intranet,我們希望在其中進行庫存管理。 我們銷售和出租警報系統,我們希望很好地了解我們辦公室中還有哪些產品、哪些產品已出租或出售、什么時間等。
目前我想到了這個數據庫設計:
每次我們創建一個新合同時,這個合同都是關於一個地點或一個項目的銷售。 所以我們有一個 Product 表(它是產品的類型:鬧鍾、鬧鍾等)和一個 Item 表,它是項目本身,帶有唯一的序列號。 我考慮過這樣做,因為我需要跟蹤特定物品的位置,如果它在客戶房屋(租用),是否已售出等。產品與特定供應商有關,我們可以與誰聯系接受命令。 但是在這里,我有一個問題,訂單表不應該與 Product 相關嗎?
這里主要關注的是庫存、項目、運動庫存之間的聯系。 我想創建一個設計,讓我能夠看到特定項目何時從我們的庫存中撤出,以及何時進入帶有日期的庫存。 這就是為什么我想到了 Movement_stock 表。 Type_Movement 是輸入/輸出。 但是我在這里有點迷茫,我真的不知道該怎么做。 這就是為什么我需要一些幫助。
我有同樣的需求,這是我如何解決您的庫存變動問題(這也成為我的問題)。
為了對庫存變動 (+/-) 進行建模,我有我的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
...
雖然這可以為您節省一張表,但您將無法使用它進行擴展,因此大多數建模(恕我直言)使用中間stock
表,主要是出於性能考慮。
缺點之一是數據重復,因為您需要重新運行上面的查詢來更新您的庫存(請參閱updatedAt
列)。
好的一面是客戶的表現。 您將通過 API 提供更快的響應。
我認為另一個缺點可能是如果您正在管理高流量商店。 您可以想象創建另一個表來存儲正在重新計算庫存的事實,並讓用戶等待直到重新計算完成(推送請求或長輪詢)以檢查他/她的每個項目是否仍然可用(庫存>= 用戶需求)。 但這是另一筆交易......
無論如何,即使股票重新計算查詢使用匿名子查詢,它實際上在大多數相對中等的商店中應該足夠快。
注意
您在product_order
看到,我復制了價格和增值稅。 這是出於可靠性的原因:在購買時凍結價格,並能夠用大量小數重新計算總數(不會丟失美分)。
希望能幫到路過的人。
編輯
在實踐中,我將它與Laravel一起使用,並且我使用了一個控制台命令,它將批量計算我的產品庫存(我還使用了一個可選參數來僅計算某個產品 id),因此我的庫存始終是正確的(相對於上面的查詢),我從不手動更新庫存表。
這是一個有趣的討論,並且還可以增加某個日期的庫存可用性......這意味着存儲:
這些產品移動中的每一個都可能來自和到達一個位置
用戶查詢將包括:
庫存設計必須考慮到用戶的查詢和用例來確定設計並打破規范化規則以在正確的時間提供足夠的性能。
需要考慮很多,這一切都取決於軟件用例。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.