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

Question

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

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：公用表，属性表。

最好的方法是什么？

Answer 1

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

Products
--------
ProductID


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


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

直接查询和行业最佳实践。

Answer 2

在不了解您的域名的情况下，我倾向于使用设计2.这将限制表格的数量，并对多个类别的不同属性进行查询，使其更具可读性和效率。

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

Answer 3

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

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

Answer 4

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

Answer 5

常用设计是最常见属性的公用表，然后是每个类别的子表，具有该类别的特殊属性。

或者，您可以使用实体值结构，但通常不推荐使用它，因为它很难查询，也不能很好地扩展。

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

Answer 6

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

如果属性不是所有相同的数据类型，那么属性这样的属性表示不可能是常见的。