库存系统：基于交易或商店数量，通过触发器更新？

Question

您将如何为 RDBMS 中的库存管理系统设计数据模型？

您会：

1. 存储每次购买的商品吗？用法，并使用 SUM() 和 GROUP BY 动态计算仓库数量？
2. 与1相同，但是每天合并数量，并使用前一天的值？
3. amount 作为 Int 字段，通过应用层更新？
4. 与3相同，但是使用DB触发器？

基于交易的库存系统似乎在捕获的细节水平方面更胜一筹，但正确实施它却更困难。性能会随着时间的推移而下降。

基于数量的库存系统似乎更容易，但可能需要额外的锁定来确保数量值是 ++ 或 -- 正确。

你会选择哪一个？

Answer 1

我很可能会采用触发路线，并在交易推送到数据库时更新数量。这使得不需要一堆子查询和计算就可以很容易地看到当前的数量是多少。

如果它是在触发器中完成的，那么您可以确保无论事务来自何处，库存表中的数量始终会更新（无论是否有通过硬插入或通过应用程序添加的事务）。

如果存在日志记录问题，请将一些日志记录到触发器中，以跟踪单独的日志记录表中之前/之后的数量。

触发器可能如下所示（未经测试）：

CREATE TRIGGER [dbo].[OrderAdded] 
   ON  [dbo].[Orders] 
   AFTER INSERT
AS 
BEGIN
    DELCARE @ProductID int; DECLARE @Qty int;
    SET @ProductID = (SELECT ProductID FROM inserted);
    SET @Qty = (SELECT Qty FROM inserted);
    UPDATE StockTable 
    SET Stock = Stock - @Qty
    WHERE ID = @ProductID

END

只要您为 ID 和 Stock 字段正确索引了 StockTable ，我就不认为会有性能问题需要担心（鉴于您没有提供任何数据库信息，我当然是在编造所有这些）。

Answer 2

如果审计跟踪很重要，您就需要交易数据。而且，我从未见过真正的系统不是这样的。

就性能而言，我会：

1. 定期捕获非规范化值 - 例如每小时或每天将
2. 涉及此非规范化过程的事务记录移动到另一个表（即从“当前”到“仓库”）。

那么总计将是该非规范化值与当前交易的总和。

这种方法还有助于备份，因为事务记录的数量可能会超过可用磁盘空间。因此，例如将仓库写到磁带备份中。