我賣酒。所以我有一個瓶子的庫存。到目前爲止，我有一個引用product和line_item的「InventoryUnit」模型。庫存管理：如何處理數據庫中已售出的庫存單位？
應該每單瓶被存儲在我的數據庫中的個人InventoryUnit對象？
什麼來降低我的庫存最好的做法是什麼？如果我賣了一瓶，我是否銷燬了InventoryUnit？或者我應該只添加一個可以「銷售」或「有庫存」的狀態欄？
我很擔心性能，可以Postgres的處理成千上萬的InventoryUnit的對象？
我真的很感謝這一個幫助。對不起，我是一個前端-傢伙，所以我真的吸在數據庫建模...
啊這是一個很難回答的問題。有沒有正確的方式雖然不同的模型會根據使用情況產生影響。
如果你跟蹤量低，但高度信息密集的股票（比如，飛機及零部件），你可能要定義每個項目的條目;如果你正在模擬大量相同的產品，並且幾乎沒有身份（就像你的情況一樣），我會專注於庫存狀態。這一切都取決於你想跟蹤物品的生命週期的深度。
問問自己「是否值得追蹤這盒餅乾的實例，或者我可以跟蹤托盤影響我現有庫存的數量？一個加油站會爲每升燃油創造一個入口嗎？
你應該跟蹤在最低水平互換庫存。換句話說，當你要從貨架上選擇一個單位時，爲了獲得正確的結果，你需要知道哪些最具體的信息。
在你的例子中，我不能只說「去拿一瓶」，或者你可以帶回酒而不是伏特加酒。我也不能說「去買一瓶伏特加酒」，因爲當我想要Ciroc時，你可能會帶回絕對伏特加。最後，我不能說「去買一瓶Ciroc」，因爲當我想要1.5L的尺寸時，你可能會帶回1L的尺寸。
我可以說：「從1.5L Ciroc底箱的前排左側取第三個瓶子」，但這樣會很愚蠢，因爲所有1.5L的Ciroc瓶子都是一樣的。 （味道放在一邊;））。
甜蜜點成爲您的庫存單位（SKU）。謝天謝地，世界上幾乎每家公司都已經爲你解決了這個問題。只需使用條形碼下的UPC編號作爲您的SKU。
在此基礎上，你的模型將是這樣的......
InventoryOnHand
- id:int
- product_id:int
- quantity:int
Product
- id:int
- sku:string
- name:string
然後，您可以增加或減少InventoryOnHand量爲東西和脫銷去。
一。是否應將每個瓶子作爲單個InventoryUnit對象存儲在我的數據庫中？
如果您可以單獨銷售它們，那麼是的，否則請通過箱子/箱子追蹤它們。
二。減少庫存的最佳做法是什麼？如果我賣了一瓶，我是否銷燬了InventoryUnit？或者我應該只添加一個 狀態欄，可以「售出」或「有貨」？
使用位置和運動的概念（運動應該是它自己的實體）。例如，OpenERP使用與此類似的「虛擬位置」。
瓶子摔碎了嗎？將其從庫存位置移至「已損壞」位置
瓶子失蹤了？將其從庫存移至「以太網」位置
發現隨機瓶子？將它從「乙醚」移到庫存
賣了一瓶？將其從庫存移至「已售出」
買了一瓶？將其從購買到庫存
三。我擔心性能，Postgres可以處理數十萬個InventoryUnit對象嗎？
Postgres可以處理數以百億計的物體。正常化。使用小數據類型。使用索引。
一些其他的事情要記住：
對於會計庫存，您還需要根據板上免費離岸價狀態計算您負責的入庫和出庫貨物的貨物。
您需要統計原材料商品（DIY釀酒東西嗎？），如果你做/安裝任何東西，以及訂貨成本工程進展等
託運貨物不屬於會計庫存計數。
什麼是數據庫中的「瓶子」。你如何區分瓶子，你需要跟蹤哪些信息？ –
我會推薦尼爾的方法。我創建了一個名爲「Transactions」的模型，它記錄了從一個模型到另一個模型的運動。比方說，你有100瓶，然後你賣或失去一些。然後，您可以記錄您獲得或銷售的所有產品。您正在考慮的系統與Quickbooks的工作方式非常相似。如果你瞭解會計，那麼這應該很容易。 –