产品库存（超市）的数据库设计

Question

在过去的几年里，我制作了简单的商店应用程序，在那里我制作了这样的简单产品表：

ID,Name,IDCategory,Size,Qty,buyprice,sellprice

数量字段在产品表中，当在交易中时，我会在该表上添加或减去它。

现在，在我的新超市应用程序中，我知道我需要设计更复杂的表来跟踪库存商品数量，因为产品现在有一个到期日期、不同的买入价（可能还有卖出价）。这是确保财务报告准确的唯一方法，我们可以获得每笔交易的实际利润。

我的新产品表是这样的

ID,Name,IDCategory,Size,ExpirationDate,SellPrice    '(I remove qty and keep sell price to simplified and sell my item at 1 price only )

设计的问题是它在数据库和编程设计中变得更加复杂，我认为我需要应用 FIFO 系统，并且在我考虑编辑事务/返回项目等时变得更加复杂。

我现在能想到的就是让表格像这样：

tblProductQty = BuyInvoiceID,Date,IDProduct,Qty

但后来我意识到这个信息已经在我的 tblBuyTransactionDetail ( *将我的购买交易（如 invoiceNo,SupplierID,Date,Total）与详细信息表（如 (InvoiceNo,IDProduct,Qty,BuyPrice,ExpirationDate)）一起保存的表）

现在我真的很困惑，我真的需要 stockTable 吗？但如果不是，则意味着我需要在交易查询之间进行加减运算才能获得一种产品的数量。

你们实际上是怎么做到的？各大超市的共同设计是什么？

注意：我目前使用 access 和 vbnet

Answer 1

我知道对于大多数 erp 系统，以下各项都有单独的表格；

购买（注意购买不一定是产品）

产品交易（您将需要它来计算先进先出股票价值）

销售（通常但不总是产品）

产品详情（描述等）

您提到了到期日。理想情况下，这些应针对个人购买进行记录。

另请注意，采购和销售通常分为标题表和明细表（发票和发票行）。

Answer 2

这两种方法都用于执行此操作，有些使用单独的 De normalized stock Table，有些在报告时计算它。 两者都是正确的方法，但以下是使用单独库存表的利弊，请根据自己的情况使用。

优点：

1. 报告会很快。
2. 报表逻辑会很简单。
3. 如果您在一段时间后提供股票结算功能，那么同样 可以通过在该表中添加一些额外的列来使用 stock 表。

缺点：

1. 单独的库存表处理更容易出错，因为每个事务都有 相关库存涨跌 也需要更新这个新股 桌子也是。
2. 如果您的库存非常频繁地涨跌 应用程序，那么它会影响的性能 系统为每只股票加减此表将被锁定 交易和更新。