2

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

你会：

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

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

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

你会选哪一个？

4

2 回答 2

3

我很可能会走触发路线，并在事务被推送到数据库时更新数量。这使得无需一堆子查询和计算就可以很容易地查看当前数量。

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

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

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

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（鉴于您没有提供任何数据库信息）。

于 2011-03-17T14:40:25.597 回答
2

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

就性能而言，我会：

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

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

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

于 2011-03-17T16:43:09.700 回答