database-design - 如何为每种产品具有许多参数的多种产品设计产品表

Question

我在表格设计方面没有太多经验。我的目标是创建一个或多个满足以下要求的产品表：


支持多种产品（电视，电话，PC等）。每种产品都有一组不同的参数，例如：


手机将具有颜色，尺寸，重量，操作系统...
PC将具有CPU，HDD，RAM ...

参数集必须是动态的。您可以添加或编辑所需的任何参数。


没有每种产品的单独表，如何满足这些要求？

Answer 1

您至少具有以下五个选项来为您描述的类型层次结构建模：


Single Table Inheritance：所有产品类型的一个表，具有足够的列以存储所有类型的所有属性。这意味着有很多列，其中大多数列在任何给定行上都是NULL。
Class Table Inheritance：一个产品表，存储所有产品类型共有的属性。然后，每种产品类型一个表，存储特定于该产品类型的属性。
Concrete Table Inheritance：没有用于常见产品属性的表。而是，每种产品类型一个表，既存储通用产品属性又存储特定于产品的属性。
Serialized LOB：一个产品表，存储所有产品类型共有的属性。额外的一列以XML，YAML，JSON或其他某种格式存储了半结构化数据的BLOB。此BLOB允许您存储特定于每种产品类型的属性。您可以使用精美的设计模式对此进行描述，例如Facade和Memento。但是，无论您是否拥有一堆无法在SQL中轻易查询的属性；您必须将整个Blob取回应用程序并在那里进行排序。
Entity-Attribute-Value：一张产品表，一张表将属性旋转为行而不是列。就关系范式而言，EAV并不是有效的设计，但无论如何，许多人仍在使用它。这是另一个答案提到的“属性模式”。有关某些陷阱，请参见有关StackOverflow上eav tag的其他问题。


我在Extensible Data Modeling演示文稿中对此进行了详细介绍。



关于EAV的其他想法：尽管很多人似乎都喜欢EAV，但我不是。这似乎是最灵活的解决方案，因此也是最好的。但是，请记住格言TANSTAAFL。以下是EAV的一些缺点：


无法使列成为强制列（等效于NOT NULL）。
无法使用SQL数据类型来验证条目。
无法确保属性名称拼写一致。
无法将外键放在任何给定属性的值上，例如用于查找表。
传统的表格布局获取结果是复杂且昂贵的，因为要从多个行中获取属性，您需要对每个属性执行JOIN。


EAV的灵活性程度使您需要在其他方面做出牺牲，这可能会使您的代码变得比以更传统的方式解决原始问题要复杂（或更糟）。

在大多数情况下，没有必要具有这种程度的灵活性。在OP有关产品类型的问题中，为每种产品类型的产品特定属性创建一个表要简单得多，因此，至少对于相同产品类型的条目，您必须实施一些一致的结构。

仅当必须允许每一行都可能具有不同的属性集时，才使用EAV。当您拥有一组有限的产品类型时，EAV会显得过大。类表继承将是我的首选。



2019年更新：我看到人们使用JSON作为解决“许多自定义属性”问题的解决方案的次数越多，我越不喜欢该解决方案。即使使用特殊的JSON functions支持查询，它也会使查询过于复杂。与存储在普通行和列中相比，存储JSON文档需要更多的存储空间。

基本上，在关系数据库中，这些解决方案都不是简单有效的。具有“可变属性”的整个想法与关系理论根本上是不一致的。

最终的结果是，您必须根据对应用程序最不利的方面选择一种解决方案。因此，在选择数据库设计之前，您需要知道如何查询数据。无法选择一种“最佳”解决方案，因为任何一种解决方案对于给定的应用程序可能都是最佳的。