库存管理数据库设计答案

【问题标题】：Stock management database design库存管理数据库设计
【发布时间】：2021-05-01 09:10:25
【问题描述】：

我正在为我的公司创建一个 Intranet，我们希望在其中进行库存管理。我们销售和出租警报系统，我们希望全面了解我们办公室里还有哪些产品、出租或出售的产品、时间等。

当时我想到了这个数据库设计：

每次我们创建新合同时，该合同都是关于地点或物品的销售。所以我们有一个 Product 表（它是产品的类型：闹钟、闹钟等）和一个 Item 表，它是项目本身，带有唯一的序列号。我考虑过这样做，因为我需要跟踪特定物品的位置，是否在客户房屋（租用），是否已售出等。产品与特定供应商相关，我们可以向其提供接受命令。但是这里，我有一个问题，订单表不应该和产品相关吗？

这里主要关注的是库存、项目、运动库存之间的联系。我想创建一个设计，让我能够看到特定商品何时从我们的库存中取出，以及它何时以日期进入库存。这就是为什么我想到了一个 Movement_stock 表。 Type_Movement 是 In / Out。但是我在这里有点迷路，我真的不知道该怎么做。这就是我寻求帮助的原因。

【问题讨论】：

为什么要重新发明轮子？那里有大量免费/非免费的库存管理系统。甚至是 ERP——因为下一个问题是如何将库存管理系统与计费、会计、然后与...集成在一起。
此外，这个问题非常广泛。您基本上是在要求我们为您设计一个库存管理系统的数据库。这不太可能在这里发生。此外，您将很多东西混合到该数据库中，例如定价或合同管理，它们不属于库存管理的一部分，并且再次扩大了您的问题。如果您确实坚持自己从头开始创建此类应用程序，那么请从财务/会计部门获取 sy 来帮助您描述流程，因为您显然对这些了解不多，这会导致很多设计问题。
@Shadow，为什么生气？没有人强迫你做任何事情。喜欢挑战并喜欢回答的人通常会在这里回答。这是他们的全部权利。在这里，唯一标识的对象和仅定量标识的对象之间存在原则上的区别。我会以这种方式设计它，对于仅定量识别的对象，表格：项目；仓库；转让；销售量;销售细节；挑战是总结每个仓库的当前数量。为此，必须将向其转移的金额相加；从中转出的金额；销售额。
@Developer 我没有从 Shadow 中看出愤怒。该人提出了两个有效的观点： (a) 本网站具有特定目的和特定参数。即回答狭隘地关注特定技术编程问题的问题，可以合理地期望有特定的解决方案。讨论整个企业的表格设计策略是一个话题，无论多么有趣或有用，都超出了本网站的目的范围。所以我投票结束。 (b) 设计数据库结构需要 OP 中似乎缺乏的领域知识，我们当然也缺乏。

标签： mysql sql database database-design

【解决方案1】：

我也有同样的需求，这就是我如何解决您的库存变动问题（这也成为我的问题）。

为了对库存变动 (+/-) 建模，我有我的 supplying 和 order 表。供应充当我的 +stock，我的订单充当我的 -stock。

如果我们停下来，我们可以计算我们的实际库存，并将其转录到这个 SQL 查询中：

SELECT
    id,
    name,
    sup.length - ord.length AS 'stock'
FROM
    product
# Computes the number of items arrived
INNER JOIN (
    SELECT
        productId,
        SUM(quantity) AS 'length'
    FROM
        supplying
    WHERE
        arrived IS TRUE
    GROUP BY
        productId
) AS sup ON sup.productId = product.id
# Computes the number of order
INNER JOIN (
    SELECT
        productId,
        SUM(quantity) AS 'length'
    FROM
        product_order
    GROUP BY
        productId
) AS ord ON ord.productId = product.id

这会给出类似的东西：

id  name            stock
=========================
 1  ASUS Vivobook       3
 2  HP Spectre         10
 3  ASUS Zenbook        0
    ...

虽然这可以为您节省一个表，但您将无法使用它进行扩展，因此大多数建模（恕我直言）使用中间 stock 表，主要是出于性能考虑。

其中一个缺点是数据重复，因为您需要重新运行上面的查询来更新您的库存（请参阅updatedAt 列）。

好的方面是客户端性能。您将通过 API 提供更快的响应。

我认为另一个缺点可能是如果您管理的是高流量商店。您可以想象创建另一个表来存储正在重新计算库存的事实，并让用户等到重新计算完成（推送请求或长轮询）以检查他/她的每个项目是否仍然可用（库存>= 用户需求）。但这是另一回事......

无论如何，即使股票重新计算查询使用匿名子查询，它实际上在大多数相对中等的商店中应该已经足够快了。

注意

您在product_order 中看到，我复制了价格和增值税。这是出于可靠性的原因：在购买时冻结价格，并且能够用很多小数重新计算总数（不会损失美分）。

希望对路过的人有所帮助。

编辑

在实践中，我将它与Laravel 一起使用，我使用console command，它将批量计算我的产品库存（我还使用可选参数仅计算某个产品ID），所以我的库存总是正确的（相对于上面的查询），我从不手动更新 stock 表。

【讨论】：

为什么需要单独的股票表？为什么不在产品中增加一列数量？
好问题，我认为这是一个设计决策，产品表中的一列也可以完成这项工作。也许支持单独表格的唯一论据是能够知道上次计算产品库存的时间。但是，如果这些信息对您制造的产品没有用处，那么我猜一列就足够了。

【解决方案2】：

这是一个有趣的讨论，也可以在某个日期增加库存可用性... 这意味着存储：

产品在特定日期的计划订单
截至特定日期的已确认订单
订单已送达
退回的订单（尤其是出租产品）

这些产品移动中的每一个都可能来自或到达一个位置

然后用户查询将包括：

我手头的总库存是多少
应在特定日期交付的产品
截至某一日期的总体库存量是多少
截至某个地点的日期，手头的库存是多少

库存设计必须考虑用户的查询和用例来确定设计并打破规范化规则以在正确的时间提供足够的性能。

需要考虑很多，这完全取决于软件用例。

【讨论】：