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

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

我拿出他们以下可能的解决方案和我最初的想法：

与每一个可能的属性的一个大表，只是把空的地方是不适用的。显然这有一些缺陷。
为每种设备类型都有一个单独的表格。这似乎可能是一个噩梦使用，如果我想打印所有设备的列表，我怎么知道哪些表查找？
拥有一个表格，其中包含通用属性和其他用于存储额外属性的外键访问的每种设备类型的表格。我大概可以完成这项工作，但这会很麻烦，只是觉得不是一个很好的解决方案。
实体属性值类型模型。只是看起来不适合我想要做的事情。

我没有很多与数据库，所以我的学习经验，因为我去这里，关于这个问题的任何链接或“必读”数据库设计篇，将不胜感激。谢谢！

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

来源

2012-07-21 neurotik

chek在下面的帖子中的答案：http://stackoverflow.com/questions/870808/entity-attribute-value-database-vs-strict-relational-model-ecommerce-question – 2012-07-21 04:11:21

这篇文章与一些其他文章相矛盾我阅读说应该避免EAV，想到任何人？ – neurotik 2012-07-21 04:37:24

选项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)

等

来源

2012-07-21 04:10:13

新设备的推出是确定的，有人希望事后添加属性是不太可能的，但可能的。中断不是问题，但是说新的属性不能被添加是不可能的，因为需要添加新的设备，并且我不能确定目前的属性将覆盖所有未来的情况。 – neurotik 2012-07-21 04:27:01

这听起来很像EAV。不要害怕！ – 2012-07-21 04:46:34

哇，这里所有人都支持EAV。不是我所期望的，令人惊讶的是，研究开始时的一些负面文章如何真的让你脱离轨道！我会放弃它。感谢大家！ – neurotik 2012-07-21 05:12:02

这对于任何SQL数据库都很难解决。 MySQL没有很好的答案。

1）工作，你可以为重要的设备类型添加一些视图。它减少了连接的数量并允许在每个字段上进行查询和索引。

2）您可以在视图中使用union all查询。 PostgreSQL和Informix有表继承。

3）这通常是一种实现选择。再次，您可以使用视图来进行连接。 4）PostgreSQL，Informix，Oracle，IBM DB2和MS SQL Server都支持XML数据类型来实现值对。

在更高层次上，您可以开发XML设备的元模型。然后你可以使用这个模型来生成模式SQL查询和CRUD代码。

来源

2012-07-21 04:07:45

我认为你面对一个常规数据库正常化。你需要一个像表：

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description

在情况下，如果有一个以上的Attribue，在属性表列表中，然后和准用产品编号等，尽量拿出第三规范化形式

Database Normalization

来源

2012-07-21 04:13:34 Andrew

这是我提到的EAV模型，不是吗？ – neurotik 2012-07-21 04:35:59

我不认为这是“常规”。 – johnny 2018-03-05 16:13:04

替代品1，2和3由Martin Fowler在他的一本书和他的网站上概述。

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

我的选择是选项3.每个人都有对事物的总体方案的地方。

EAV可以在飞行中很好地添加新的属性。但是，当将数据转化为有用的信息时，EAV数据库可能是一场噩梦。