1

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

但是由于该软件还必须能够管理库存，所以我有点困惑如何设计一个数据库来支持这个功能。

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

虚拟模型

我计划为整个商店中的每种可用产品在 ProductInventory 上添加一条记录，每当我的客户想要销售某种产品​​的某些产品时，软件将：按条形码过滤产品，按 PiecesLeft 升序排序并从中减去这些产品结果集中的顶级产品。

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

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

因此，总而言之，我想要的是您可以给我的任何建议以及对我的方法的意见。

感谢您的时间。

4

3 回答 3

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

在数据库端处理它并不是特别难。除了一个普通的旧库存模式之外，您还需要一些描述有效转换的表——您不能将一包香烟转换为一瓶啤酒——并且您需要存储过程或应用程序代码来进行转换.

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

于 2013-03-10T00:57:22.450 回答
0

You say you are developing a complete solution so I assume you are also storing the sales in the database.

In your Product table you could keep track what the number of pieces for that product are. In your OrderRow (or whatever you would be calling it) you then keep track of how many pieces are sold.

To optimize this and decrease the need for joins you could for example add a computed persisted column to Product that holds the total number of pieces - the number of sold pieces.

That is all I can think of with your limited information.

于 2013-03-10T00:54:10.123 回答
0

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

关于您的香烟示例-就您的应用程序而言，我会说盒子本身就是一种产品（它可能作为产品表中的自我关系或作为一个单独的实体来实现-说它selable_product有自己的价格-我会希望块比 10 包便宜一点）

于 2013-03-10T00:37:56.977 回答