如何为多种产品设计一个产品表，每个产品有很多参数

Question

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

>

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

>

手机将有颜色、大小、重量、操作系统...

PC将有CPU、HDD、RAM...

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

如果每种产品没有单独的表，我怎么能满足这些要求呢？

Answer 1

@石心

我会一直用EAV和MVC在这里。

@比尔·卡尔文

以下是EAV的一些缺点：

• 无法使列成为强制列（相当于NOT NULL)。
• 无法使用SQL数据类型验证条目。
• 无法确保属性名称的拼写一致。
• 无法在任何给定属性的值上放置外键，例如查找表。

你在这里提到的所有事情：

• 数据验证
• 属性名称拼写验证
• 必填列/字段
• 处理依赖属性的破坏

在我看来，根本不属于数据库，因为没有一个数据库能够像应用程序的编程语言那样在适当的级别上处理这些交互和需求。

在我看来，以这种方式使用数据库就像用石头钉钉子一样。你可以用一块石头来做，但你不是应该用一把锤子吗？锤子更精确，而且是专门为这种activity设计的吗？

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

这个问题可以通过对部分数据进行很少的查询并用您的应用程序将其处理成表格式布局来解决。即使您有600GB的产品数据，如果您需要来自此表中每一行的数据，您也可以成批地处理它。

更进一步地说，如果您希望改进查询的性能，您可以选择某些操作，例如报告或全局文本搜索，并为它们准备索引表，这些索引表将存储所需的数据，并且将定期重新生成，比如说每30分钟一次。

您甚至不需要关心额外数据存储的成本，因为它一天比一天便宜。

如果您仍然关心应用程序操作的性能，您可以使用Erlang、C++、Go语言对数据进行预处理，然后在主应用程序中进一步处理优化后的数据。

Answer 2

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

>

单表继承：用于所有产品类型的一个表，具有足够的列来存储所有类型的所有属性。这意味着很多列，其中大多数列在任何给定行上都是空的。

类表继承：产品的一个表，存储所有产品类型通用的属性。然后每个产品类型一个表,存储特定于该产品类型的属性。

具体表继承：公共产品属性没有表。相反，每个产品类型都有一个表，存储通用产品属性和特定于产品的属性。

序列化LOB：产品的一个表，存储所有产品类型通用的属性。一个额外的列存储一个半结构化数据BLOB，格式为XML、YAML、JSON或其他格式。此BLOB允许您存储特定于每个产品类型的属性。你可以用花哨的设计模式来描述这一点，比如Facade和memento。但是，不管您有一个在SQL中不容易查询的属性块；您必须将整个blob取回应用程序并在那里进行排序。

Entity-Attribute-Value：一个用于产品的表，一个将属性透视到行（而不是列）的表。EAV不是一个有效的关于关系范式的设计，但许多人仍然使用它。这就是另一个答案提到的“属性模式”。请参阅StackOverflow上的eav标记的其他问题，了解一些陷阱。

我在一个演示文稿“可扩展数据建模”中对此作了更多的介绍。

关于EAV的附加想法：虽然很多人似乎都青睐EAV，但我不是。这似乎是最灵活的解决方案，因此也是最好的。然而，请记住这句格言Tanstaafl。以下是EAV的一些缺点：

• 无法使列成为强制列（等效于not null)。
• 无法使用SQL数据类型验证条目。
• 无法确保属性名称的拼写一致。
• 无法在任何给定属性的值上放置外键，例如查找表。
• 在常规表格式布局中获取结果既复杂又昂贵，因为要从多行中获取属性，需要为每个属性执行join操作。

EAV为您提供的灵活性需要在其他方面做出牺牲，这可能会使您的代码与以更常规的方式解决原始问题时一样复杂（或更糟糕）。

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

只有当必须允许每一行具有一组不同的属性时，我才会使用EAV。当您的产品类型有限时，EAV是矫枉过正的。类表继承将是我的首选。

更新2019：我越看到人们使用JSON作为“多自定义属性”问题的解决方案，我就越不喜欢那个解决方案。这使得查询过于复杂，即使在使用特殊的JSON函数来支持查询时也是如此。存储JSON文档需要更多的存储空间，而不是存储在常规行和列中。

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

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