1

我们当前的商店库存数据库布局包括一个表，其中包含每个项目的记录，并包括项目属性，如价格、成本、描述、SKU 等。然后每个商店都有一个包含 SKU 和数量的表，以及一个根据 SKU，每个商店的其他一些属性都不同。

虽然这比在 Items 表中为每个商店的数量设置一列要好，但这似乎也是一个有点丑陋的解决方案，因为当添加新商店时，您需要选择新表并添加新商品，您不仅要插入 items 表，还要插入每个单独的 store 表。

有没有比我看到的更好的方法来解决这个问题？感觉好像有。

4

4 回答 4

1

为什么没有包含 SKU、StoreId 和库存级别的库存表？

例如

Sku    | StoreId   | StockLevel
1234   | 001       | 15
1235   | 001       | 16
1234   | 002       | 8
1235   | 002       | 0

所以，商店 002 的 sku 1235 缺货，但商店 001 有很多。此表格布局还允许您使用类似

select sku, sum(StockLevel) from stock group by sku
于 2010-01-13T16:26:31.770 回答
0

通过遵循数据规范化规则，您可能希望创建一个如下所示的表：

store_id | sku    | quantity | other_attributes ... 
---------+--------+----------+---------------------
    1000 | 129832 |      234 |                  ...
    1000 | 129833 |      334 |                  ...
    1000 | 129834 |       23 |                  ...
    1001 | 129832 |        0 |                  ...
    1001 | 129833 |       12 |                  ...
    1001 | 129834 |       10 |                  ...
    ...

本质上，它是一个 store_inventory 表。这样，您可以通过以下方式过滤到给定的商店

WHERE store_id = 1000

ETC...

于 2010-01-13T16:28:50.920 回答
0

据我所知，你真的想要三张桌子：

产品

ProductID
Price
Description
...

店铺产品

ProductID
StoreID
Quantity
...

店铺

StoreID
Address
...

这是一个完全有效且规范化的数据库设计，听起来基本上就是您现在所拥有的。

于 2010-01-13T16:29:39.423 回答
0

听起来它从正确的路径开始，为项目的所有常见属性提供一个表。

所有商店的库存计数应该在一个单独的附加表中，而不是每个商店都有一个单独的表，使用 Item's Key 和 Store's Key 作为该表上的组合主键。

例如

项目

ItemKey
名称
价格
SKU

专卖店

StoreKey
名称
地址

存货

StoreKey
ItemKey
数量

在 Inventory 表上同时使用 StoreKey 和 ItemKey 将使您的记录保持唯一。

这将使您不仅可以轻松查找单个商品，还可以查找以下内容：
一家商店的所有商品数量（按 StoreKey
） 所有商店的一件商品数量（按商品密钥） 所有商店中的
商品数量（按数量）
等

于 2010-01-13T16:36:37.640 回答