如何为具有附加属性的库存交易/移动设计数据库？答案

【问题标题】：How to design database for stock inventory transactions/movements with additional properties?如何为具有附加属性的库存交易/移动设计数据库？
【发布时间】：2021-10-22 15:31:27
【问题描述】：

我正在设计一个库存管理系统。

我目前的理解是，它应该类似于银行交易，您从位置 A 取出库存并将其放在位置 B。在这种情况下，我会有一个这样的交易表：

id  
product_id  
amount_of_units
from_location_id    
to_location_id

为了获得手头的数量，我会遍历所有交易并为一个位置吐出总和。到目前为止一切顺利。

问题在于一次可以改变不止一件事。它的状态可以变成ready 或waiting。要跟踪 status，我必须添加 2 列：

id  
product_id
amount_of_units
from_location_id    
to_location_id
from_status_id
to_status_id

我有 10 个左右可以更改的属性，我需要保留这些属性的历史记录。我是否使用 from 和 to 前缀将它们全部添加到此表中？还是我必须将它们拆分为单独的表：location_transactions 和 status_transactions，在这种情况下我将如何连接它们？

研究：我读了一堆问题和answers，但它们都围绕着简单的交易表或复式系统。不包含正在交易或更改属性的项目的附加信息。

【问题讨论】：

Inventory database design 是一个地方。
我在研究中读到过——它似乎没有提出同样的问题——how do you structure the database if you have other properties changing of the inventory?
您为 Product、ProductStatus 和 ProductLocation 创建单独的表。如果您还有七个属性，那么您将再创建七个 ProductProperty 表。 ProductStatus 有一个状态指示器和一个时间戳。所有其他属性表的结构都相似。
好的，假设我导入了 30 个产品 waiting 状态。我为事务表创建了一条记录，并为 waiting 创建了一条包含 30 个单位的记录。如果 15 变成状态 ready 那么我在状态表中再做一条记录，对吗？但是我将如何连接它们？换句话说，如果我将 5 标记为 broken，我们怎么会说它来自等待者或准备者？似乎需要以某种方式相互联系......
您有一个用于此目的的事务表。每个属性更改都需要一个事务行。 Product 和 ProductProperty 表保持当前状态。 ProductProperty 表包含基于旧时间戳的历史记录。 Transaction 表显示属性更改。

标签： database-design inventory-management

【解决方案1】：

我可能会创建一个如下所示的事务表：

Transaction
-----------
Transaction ID
Product ID
Units
Prior Status
Current Status
Prior Quality
Current Quality
...
Timestamp

来自您之前的评论示例

1, 1, 30, null, intake, null, waiting, timestamp
2, 1, 15, null, null, waiting, ready, timestamp
3, 1, 5, null, null, ready, broken, timestamp

【讨论】：