如何为许多种具有许多参数的产品设计产品表格

Question

如何为许多种具有许多参数的产品设计产品表格

database-designrelational-databasedatabase-schema

175

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

支持多种产品（电视、手机、电脑等）。每种产品都有不同的参数集，例如：
- 手机将具有颜色、尺寸、重量、操作系统等参数。
- 电脑将具有CPU、硬盘、内存等参数。
参数集必须是动态的。您可以添加或编辑任何参数。

如何在不为每种产品单独创建一个表格的情况下满足这些要求？

- StoneHeart

更多关于EAV和JSON的内容：http://mysql.rjweb.org/doc.php/eav - Rick James

4个回答

13

@StoneHeart

我会选择 EAV 和 MVC。

@Bill Karvin

下面是使用 EAV 的一些缺点:

无法使列成为强制性的（等同于 NOT NULL）。

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

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

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

我的看法是，你提到的所有这些事情：

数据验证
属性名称拼写验证
强制性列/字段
处理依赖属性的销毁

在我看来并不适合放在数据库中，因为没有一个数据库能够像应用程序的编程语言一样在正确的层次上处理这些交互和要求。

在我看来，以这种方式使用数据库就像用石头敲钉子。你可以用石头做到，但你难道不应该使用更精确、专门设计用于这种活动的锤子吗？

从传统的表格布局中获取结果非常复杂和昂贵，因为要获取多行的属性，需要为每个属性进行连接。

这个问题可以通过对部分数据进行几次查询并用应用程序将其处理成表格布局来解决。即使你有 600GB 的产品数据，如果需要从这个表中的每一行获取数据，你也可以分批处理它们。

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

你甚至不必担心额外数据存储的成本，因为它的价格每天都在降低。

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

- Pawel Barcik

你可以随时使用Erlang、C++、Go语言来预处理数据。你的意思是，不用数据库，而是使用Go语言吗？你能详细说明一下吗？ - Green

1

我完全同意。EAV是一种可行的选择，特别是如果您需要灵活性水平，允许您添加新类型的产品和参数而无需进行数据库架构更改，我的意思是通过您的应用程序直接在生产中实现。在那儿，我做到了。适合我工作。关于缓慢查询...这里有人听说过缓存吗？ ;) - pawel.kalisz

@Green 我已经编辑了最后一段，使其更加清晰，但它是关于将原始的EAV数据传递给一个能够快速且在内存使用效率高的语言处理数据转换、树结构查找或任何基本的MapReduce操作的过程。具体取决于需要优化什么。 - Pawel Barcik

10

如果我使用“类表继承”意味着：

- 为产品使用一个表，存储所有产品类型共有的属性。然后，每种产品类型都有一个表，存储特定于该产品类型的属性。 -Bill Karwin

这是我最喜欢的 Bill Karwin 的建议之一... 我可以预见到一个缺点，我将尝试解释如何避免它成为问题。

当一个属性仅适用于一种类型，然后变成适用于2种、3种等类型时，我应该有什么应急计划呢？

例如：（这只是一个例子，不是我的真实问题）

如果我们销售家具，我们可能会销售椅子、灯、沙发、电视等。电视类型可能是我们唯一销售的具有功耗的类型。因此，我会在 tv_type_table 上放置 power_consumption 属性。但随后我们开始销售家庭影院系统，它们也有 power_consumption 属性。好吧，这只是另一种产品，所以我会在 stereo_type_table 上添加此字段，因为这可能是最简单的方法。但随着时间的推移，当我们开始销售越来越多的电子产品时，我们意识到 power_consumption 足够广泛，应该在 main_product_table 中。现在我该怎么办？

将该字段添加到 main_product_table。编写一个脚本来循环遍历电子产品，并将每个 type_table 中的正确值放入 main_product_table。然后从每个 type_table 中删除该列。

现在，如果我始终使用同一 GetProductData 类与数据库进行交互以获取产品信息，则如果代码有任何更改，现在需要重构的应该只是该类。

- JD Isaacks

4

你可以拥有一个产品表和一个单独的产品附加信息表，其中包含3列：产品ID、附加信息名称、附加信息值。如果颜色被许多但不是所有种类的产品使用，您可以在产品表中将其作为可空列，或者将其放在产品附加信息中。

这种方法不是关系数据库的传统技术，但我在实践中看到它被广泛使用。它可以灵活地使用并具有良好的性能。

Steve Yegge称之为属性模式，并写了一篇长篇文章介绍如何使用它。

- RossFabricant

4

属性模式就是另一种名为实体-属性-值的模式。它被广泛使用，但将其存储在关系数据库中会违反规范化规则。 - Bill Karwin

2

说实话，当我读到@Bills回答中EAV的描述时，我并没有完全理解他所解释的内容。但是当你说“3列：产品ID、附加信息名称、附加信息值”时，我就明白了这个概念。而且我以前也做过这个，遇到了问题。然而，我现在不记得那些问题是什么了。 - JD Isaacks

1

在这种模式中，一个常见的问题是我们不知道需要多少个JOIN才能获取所有属性。 - Omid

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bill Karwin · Accepted Answer

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

单表继承：所有产品类型都存储在一个表中，具有足够的列来存储所有类型的所有属性。这意味着在任何给定的行上，大多数列都为空。
类表继承：一个产品表，存储所有产品类型共有的属性。然后是每种产品类型的一个表，存储特定于该产品类型的属性。
具体表继承：没有用于通用产品属性的表。相反，每种产品类型都有一个表，存储通用产品属性和特定于产品的属性。
序列化LOB：一个产品表，存储所有产品类型共有的属性。一个额外的列存储半结构化数据的BLOB，可以是XML、YAML、JSON或其他格式。这个BLOB允许您存储每种产品类型特定的属性。您可以使用复杂的设计模式来描述它，例如Facade和Memento。但无论如何，您都有一堆不容易在SQL中查询的属性，必须将整个BLOB取回应用程序并在那里进行排序。
实体-属性-值：一个产品表和一个将属性旋转到行而不是列的表。EAV不是关系范式下的有效设计，但仍有很多人使用它。这是另一个回答中提到的“属性模式”。在StackOverflow上查看其他带有eav标签的问题以了解一些陷阱。

我在一份演示文稿中写了更多关于这个的内容，可扩展数据建模。

关于EAV的一些想法：虽然许多人似乎喜欢EAV，但我不喜欢。它似乎是最灵活的解决方案，因此也是最好的。但是，请记住TANSTAAFL（没有免费午餐的道理）。以下是EAV的一些缺点：

无法使列强制为必填项（相当于NOT NULL）。
无法使用SQL数据类型验证条目。
无法确保属性名称的拼写一致。
无法在任何给定属性的值上放置外键，例如用于查找表。
以传统的表格布局获取结果很复杂且昂贵，因为要获取来自多个行的属性，需要为每个属性进行JOIN。

EAV提供的灵活性需要在其他领域做出牺牲，可能会使您的代码变得复杂（或更糟），而不是以更传统的方式解决原始问题。

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

只有当每行必须允许潜在具有不同属性集时，才会使用EAV。当您拥有有限的产品类型集时，EAV是过度的。类表继承将是我的首选。

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

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

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