良好的数据库设计,可变数量的属性

Question

我正在尝试创建一个包含设备列表的数据库.所有设备都具有某些共同属性(例如制造商,型号#,序列号等),然后还有其他特定于某个设备的属性(即,调制解调器将具有访问权限#,而太阳能电池板将具有输出容量).我不确定如何用良好的数据库设计原则来表示这些不断变化的属性,我尝试过在网上搜索,但我并不完全确定要搜索什么.

我想出了以下可能的解决方案以及我对它们的初步想法:

1. 有一个包含每个可能属性的大表,只需将null放在不适用的地方.显然这有一些缺陷.

2. 为每种设备类型单独设置一个表.这似乎可能是一个噩梦,如果我想打印所有设备的列表,我怎么知道要查找哪些表？

3. 有一个包含公共属性的表,以及使用外键访问的每个设备类型的其他表来存储额外的属性.我可能会做这个工作,但它会很麻烦,只是感觉不是一个很好的解决方案.

4. 实体 - 属性 - 值类型模型.只是看起来不太适合我想做的事情.

我没有很多数据库的经验,所以我在学习这里,任何与此问题相关的链接或"必读"数据库设计的文章都将受到赞赏.谢谢!

编辑:首先,我发现我需要谷歌"继承映射",这可能会帮助其他有类似问题的人.为了解决这个问题,我最终使用了#2和#3的混合体.它实际上非常简单,运行良好,并且解决了在没有EAV复杂性的情况下添加额外设备类型的问题.感谢所有的意见和建议!

Answer 1

选项 1、2 和 3 有一个非常严重的缺陷：当有人想出一个新属性时，您必须修改底层表架构。在选项 1 的情况下，问题因可能引入新设备类型而变得更加复杂。您有多确定属性集始终是固定的？您对中断或告诉客户不，您不能拥有新属性感到高兴吗？

如果您很可能对常见属性进行查询，您可以尝试混合 3 和 4，在拆分属性类型而不是设备类型时抛出破折号 2，这似乎更不稳定。如果我理解正确，选项 4 是选项 1 的标准形式版本，它解决了其所有固有问题（稀疏性和脆性）。

INVENTORY( id*, model, manufacturer, serial )
ATTRIBUTE( id*, name, type, description )
INVENTORY_FACT_STRING( inv_id*, attr_id*, value )
INVENTORY_FACT_NUMBER( inv_id*, attr_id*, value )
INVENTORY_FACT_LIST_STRING( inv_id*, attr_id*, ordinal*, value )

等等。