0

我想在我的数据库中存储一些产品数据。起初我想有一张product桌子和product info一张桌子，但不确定是否应该将它们全部合并到一张桌子中。

例子

Coke - 355 ml

Product.Name = Coke
ProductInfo.Size = 355
ProductInfo.UnitType = ml

Coke - 1 Liter
Product.Name = Coke (would not be duplicated...just for illustration purposes)
ProductInfo.Size = 1
ProductInfo.UnitType = L

如果我这样做了，那么我当然不会重复“名称”两次。我当时的计划是我可以很容易地找到同一产品的所有尺寸，因为我所要做的就是查看任何给定项目的多方面关系。

但问题是，所有数据都将由用户驱动并输入。有人可能会写“Coke a Cola”而不是“Coke”，现在这将被视为两种不同的产品，就像我去查看是否输入了名为“Coke a Cola”的产品但它不知道要检查“可乐”也是如此。

这导致我不得不像部分匹配一样尝试找到它，但是如果有人有一些通用品牌会发生什么，那就是“可乐”并且也会匹配。

这让我想到，也许没有必要将数据分开，因为对我来说，似乎很有可能一切最终都会成为它自己的产品。

4

3 回答 3

2

这两种方法都有优点。将它们分开，您称为“产品”的表，我会称为“品牌”，而“产品信息”是您的实际“产品”表，包含有关该品牌的实际可售商品的信息（12 盎司罐头或升瓶可乐）。

或者，您可以进一步将其标准化为品牌、产品（此处为经典可乐，可能与健怡可乐或无咖啡因可乐相反）和单位尺寸（罐装或瓶装；这些不仅适用于经典可乐，还适用于健怡可乐、百事可乐或 Dr胡椒）。

如果你对这些数据进行非规范化，你不会在命名方面重复太多，但你会复制相当多的度量单位数据。问题是确保您的产品记录品牌一致（非规范化意味着您需要一些其他方法来确保您的产品具有相同的品牌），还是避免两个表之间的连接（有成本加入，虽然如果你可以在索引字段之间加入，它通常很小）。

于 2013-07-09T17:09:51.573 回答
0

使用两个表进行 Header-Detail 排列的唯一令人信服的理由是，Coke无论包装如何，属性都相同。现在，我没有看到任何类似的属性。所以一张桌子盖住了它。你可能会说，“但我将来可能会想到类似的事情。” 这可能是制作两张桌子的原因；但是（与对数据库模式的多种更改不同）稍后当您知道有需要时，这可能不会太难分成两个表。

我明白导致几乎匹配记录的错误的观点。我认为这不是此表级别的考虑因素，您应该将其作为记录编辑的一部分来解决。

于 2013-07-09T17:11:01.497 回答
0

做到这一点的最佳方法是将您的产品或项目表放在其自己的表中，其中包含 ID、SKU 编号、简短描述、活动等字段……然后您的“多”表包含其他项目属性，这些属性可以通过ID加入；一对多的关系。为了解决用户输入问题，您有一个与库存选择或项目选择相关联的组合框。通过这种方式，您可以强制执行数据完整性。好吧，我就是这样做的。

这篇文章有一些关于数据库设计的有用链接

于 2013-07-09T17:21:19.207 回答