零售销售数据库设计

Question

我正在为某些业务开发完整的解决方案。我有一个特定的要求：系统必须能够按件记录产品销售，让我解释一下：如果一盒香烟包含20件，软件必须能够为整个盒子或两支香烟注册销售

但由于该软件还必须能够管理库存，我对如何设计数据库以支持此功能感到困惑。

这是一个虚拟的例子，我几秒钟前就生成了它，所以我知道它很可怕，我只是想展示一个简单的例子。

我打算在ProductInventory上为整个商店中的每个可用产品添加一条记录，每当我的客户想要销售软件将要销售某些产品的某些产品时：按条形码过滤产品，通过PiecesLeft按升序排序结果集中顶级产品的碎片。

这是正确的方法吗？我对这种方法感到不安，因为我认为它会在ProductInventory上产生太多记录，你们怎么想？你会怎么做？

我打算合并具有相同条形码和PiecesLeft的产品以减少记录，但我不知道该怎么做（也许使用触发器？）

所以，总结一下，我想要的是你能给我的任何建议和对我的方法的看法。

感谢您的时间。

Answer 1

当您考虑库存时，问题是您存储的库存不一定是您销售的库存。因此，我认为正确的方法需要一个能够准确地将一种“类型”的库存转换为另一种库存的业务流程。

假设您从存储的库存中开始使用100箱卷烟。有人进来想要两根香烟。对于准确的库存，转换必须如下所示。

First transformation
100 cartons -> 99 cartons
               10 packs

Second transformation
99 cartons
10 packs ->     9 packs
               20 cigarettes

最后，仅售两支卷烟，因此您的交易结束库存就是这样。

99 cartons
 9 packs
18 cigarettes

在数据库方面处理它并不是特别困难。除了普通的旧库存模式之外，您还需要一些描述有效转换的表 - 您无法将卷烟包转换成啤酒瓶 - 并且您需要存储过程或应用程序代码做转换。

处理条形码高度依赖于应用程序。在当地的托儿所（您购买植物和幼苗），条形码标签经常脱落或迷路。收银员有一个包含所有条形码的笔记本。当工厂缺少条形码时，他们会扫描书中的条形码。

Answer 2

首先，我建议摆脱自然PK（条形码）。它可能（并且可能应该是）对条形码字段的唯一约束，但不是PK。

关于你的卷烟示例 - 我说这个盒子本身就是你的应用所关注的产品（它可以作为产品表中的自我关系或作为一个单独的实体实现 - 比如selable_product有它自己的价格 - 我希望块比10包便宜一点）

Answer 3

您说您正在开发complete solution所以我假设您也在销售数据库中。

在Product表中，您可以跟踪该产品的件数。 在你的OrderRow（或任何你称之为的东西）中，你可以跟踪出售的件数。

为了优化这一点并减少对连接的需求，您可以例如将计算的持久列添加到Product，其中包含总件数 - 已售出的件数。

这是我能用你有限的信息想到的全部。