数据库设计 - 具有属性的多类别产品

Posted 2023-03-24

【中文标题】数据库设计 - 具有属性的多类别产品

【英文标题】：Database design - multi category products with properties

【发布时间】：2009-10-19 18:51:57

【问题描述】：

我正在为供应商设计一个基本的库存系统。 他们有许多不同的产品类别。 每个产品类别都有许多不同的属性。

A - x1, x2, x3, a1, a2, a3; B - x1, x2, x3, b1, b2, b3, b4; C - x1、x2、x3、c1、c2；

Laptop - Make, Price, Quantity, Processor, OS, Hard drive, Memory, Video Card etc 
Monitor - Make, Price, Quantity, Size, ContrastRatio, Resolution etc 
Server - Make, Price, Quantity, Processor, OS, Memory, Netowrking etc

设计 1：每个类别都有不同的表格。 设计2：公用表、属性表。

最好的方法是什么？

【问题讨论】：

你可能想用更多真实的例子来重新陈述这个问题。这有点难以理解。

您好 JohnFx：这是一个示例：笔记本电脑 - 制造商、价格、数量、处理器、操作系统、硬盘驱动器、内存、显卡等 显示器 - 制造商、价格、数量、尺寸、对比度、分辨率等服务器 - 制造商、价格、数量、处理器、操作系统、内存、网络等

@Natkeeran：请更新您的问题。不要评论你的问题。请更新。

【参考方案1】：

绝对不想不必要地增加模式（奥卡姆规则，你知道）。安排多对多关系的标准方式只是一个中间表：

Products
--------
ProductID


Categories
----------
CategoryID


ProductCategories
-----------------
ProductID
CategoryID

查询简单，行业最佳实践。

【讨论】：

是的，就像他说的那样。产品可以属于许多类别，反之亦然，等等。好东西。 [产品]->[产品类别]

【参考方案2】：

如果不了解您的域的更多信息，我会倾向于使用设计 2。这将限制表的数量，并使对多个类别的不同属性的查询更具可读性和效率。

如果您有少量的静态类别并且每个类别都有不同的属性，那么设计 1 值得考虑。如果是这种情况，您仍然可以通过创建属性字典表来使用设计 2。在这里，您将有一个包含属性属性键/属性名称对的表。然后您的类别表可以包含类别 id、属性 id、属性值列。如果所有属性都具有相同的数据类型，这很有效，但如果它们不具有相同的数据类型，则会变得很尴尬。

【参考方案3】：

使用设计 1，每个类别使用不同的表格。

如果属性不是全部相同的数据类型，那么设计 2 将会很痛苦。如果没有，它将迫使您将它们全部存储为字符串并编写大量强制转换代码。这也妨碍了简单的 DB 级数据类型验证。

【讨论】：

这真的取决于 OPs 的要求。如果 OP 期望类别具有大不相同的类别和数据类型数量，那么完全放弃关系模型并使用 CouchDB 实际上可能是一个好主意。

CouchDB +1，但我认为这可能不在他/她控制的范围内。

【参考方案4】：

使用第二个选项将需要对每个查询进行连接，使用第一个选项会使查询变得更加困难，因为您将拥有许多表，并且您现在必须决定要查询哪个表。我更喜欢第二种选择，因为从长远来看，应用程序开发更简单（但我可能很懒惰）。

【参考方案5】：

通常的设计是用于最常见属性的公共表，然后为每个类别创建一个具有该类别特殊属性的子表。

您也可以使用实体值结构，但一般不建议这样做，因为它难以查询且无法很好地扩展。

人们经常忘记的一件事是将购买时的价格存储在库存中物品的记录中（我认为这是常见属性之一）。如果您依赖产品表中的价格，它会随着价格的变化而更新，但出于会计目的，这不是为商品支付的价格。当您被审计或报税时，这可能会非常糟糕！

【讨论】：

/me shudders 你必须提醒我有关价格点、折扣、免税...

我也感到不寒而栗，我不得不修复一个错误地使用产品表来获取价格的库存数据库。

【参考方案6】：

“如果属性不是全部相同的数据类型，那么设计 2 将会很痛苦。”

如果属性不是所有相同的数据类型，那么这些属性所代表的属性不可能是共同的。