database-design - 如何为多种产品设计产品表，其中每种产品都有很多参数

Question

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

支持多种产品(电视、电话、PC 等)。每种产品都有一组不同的参数，例如:

手机将具有颜色、尺寸、重量、操作系统...

PC 将有 CPU、HDD、RAM...

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

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

Answer 1

您至少有以下五个选项可用于对您描述的类型层次结构进行建模:

Single Table Inheritance :所有产品类型的表，有足够的列来存储所有类型的所有属性。这意味着很多列，其中大多数在任何给定行上都是 NULL。

Class Table Inheritance : 一张产品表，存储所有产品类型的通用属性。然后每个产品类型有一个表，存储特定于该产品类型的属性。

Concrete Table Inheritance : 没有常见产品属性的表格。相反，每个产品类型有一个表，存储常见的产品属性和产品特定的属性。

Serialized LOB :Products 的一张表，存储所有产品类型通用的属性。一个额外的列以 XML、YAML、JSON 或某种其他格式存储半结构化数据的 BLOB。此 BLOB 允许您存储特定于每种产品类型的属性。您可以使用花哨的设计模式来描述这一点，例如 Facade 和 Memento。但是不管你有一堆不能在 SQL 中轻松查询的属性；您必须将整个 blob 取回应用程序并在那里进行分类。

Entity-Attribute-Value :一张表用于产品，一张表将属性转为行，而不是列。就关系范式而言，EAV 不是一个有效的设计，但无论如何很多人都在使用它。这是另一个答案提到的“属性模式”。通过 eav tag 查看其他问题在 StackOverflow 上了解一些陷阱。

我在演示文稿中写了更多关于此的内容， Extensible Data Modeling .

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

无法强制列(相当于 NOT NULL )。

无法使用 SQL 数据类型来验证条目。

无法确保属性名称拼写一致。

无法将外键放在任何给定属性的值上，例如查找表。

在传统表格布局中获取结果既复杂又昂贵，因为要从多行获取属性，您需要执行 JOIN对于每个属性。

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

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

仅当必须允许每一行潜在地具有一组不同的属性时，我才会使用 EAV。当您拥有一组有限的产品类型时，EAV 是多余的。类表继承将是我的首选。

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

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

归根结底，您必须根据对您的应用程序最不利的解决方案来选择一种解决方案。因此，在选择数据库设计之前，您需要知道将如何查询数据。没有办法选择一个“最佳”解决方案，因为任何解决方案都可能最适合给定的应用程序。