我应该使用 EAV 数据库设计模型还是很多表答案

【问题标题】：Should I use EAV database design model or a lot of tables我应该使用 EAV 数据库设计模型还是很多表
【发布时间】：2013-02-21 08:59:34
【问题描述】：

我开始了一个新的应用程序，现在我正在寻找两条路径，但不知道哪个是继续的好方法。
我正在构建类似 电子商务 网站。我有一个类别和子类别。
问题是网站上有不同类型的产品，每个产品都有不同的属性。并且网站必须能够通过这些产品属性过滤。
这是我最初的数据库设计：

Products{ProductId, Name, ProductCategoryId}
ProductCategories{ProductCategoryId, Name, ParentId}
CategoryProperties{CategoryPropertyId, ProductCategoryId, Name}
ProductPropertyValues{ProductId, CategoryPropertyId, Value}

现在经过一些分析，我发现这个设计实际上是EAV模型，我读到人们通常不推荐这种设计。
似乎一切都需要动态 sql 查询。

这是一种方式，我现在正在研究它。

我看到的另一种方式可能被命名为 LOT WORK WAY，但如果它更好，我想去那里。做表

Product{ProductId, CategoryId, Name, ManufacturerId}

并在数据库中进行表继承，这意味着使表像

Cpus{ProductId ....}
HardDisks{ProductId ....}
MotherBoards{ProductId ....}
erc. for each product (1 to 1 relation).

我知道这将是一个非常大的数据库和非常大的应用程序域，但它是否比采用 EAV 设计的选项更好、更容易且性能更好。

【问题讨论】：

我不同意你的初始设计是 EAV。
ProductPropertyValues 表不是 EAV 吗？来吧。
为什么你认为不是？
EAV 是一种反模式。尽量避免。
是的。您还可以考虑对某些可能只想搜索但不需要计数或排序的列使用带有 SQLXML 函数的 XML 列

标签： sql database database-design relational-database entity-attribute-value

【解决方案1】：

EAV 很少能赢。在您的情况下，我可以看到 EAV 的吸引力，因为不同的类别将具有不同的属性，否则将很难管理。但是，假设有人想搜索“所有具有 3 个以上盘片、使用 SATA 接口、转速为 10k rpm 的硬盘驱动器”？您在 EAV 中的查询会很痛苦。如果你想支持这样的查询，EAV 就不行了。

但是还有其他方法。您可以考虑一个带有扩展数据的 XML 字段，或者，如果您使用的是 PostgreSQL 9.2，则可以考虑一个 JSON 字段（虽然 XML 更容易搜索）。这将为您提供更大范围的可能搜索，而无需 EAV 的麻烦。折衷方案是架构实施会更加困难。

【讨论】：

是的，这正是迫使我问这个问题的问题。我已经制作了EAV结构和不同类别的过滤产品，迫使我使用动态sql并且很痛苦。所以我开始将数据库重组为更小的表，现在我对我的 40 个继承产品表感到满意。但仍在分析问题...

【解决方案2】：

This questions 似乎更详细地讨论了这个问题。

除了那里讨论的性能、可扩展性和复杂性之外，还要考虑：

SQL Server等SQL数据库具有全文检索功能；因此，如果您有一个描述产品的字段 - 全文搜索会将其编入索引并能够提供高级语义搜索
看看现在风靡一时的 no-sql 系统；它们的可扩展性应该非常好，并且它们为非结构化数据（例如您拥有的数据）提供支持。 Hadoop 和 Casandra 是很好的起点。

【讨论】：

NoSQL 数据库不是我对这个项目的兴趣，所以我不能考虑它们。 ...single field describing the product ... 您的意思是将所有可能的属性作为列添加到产品中吗？那将是一个有 1000 列的表，我不能这样做:(
不，包含所有这些属性的单列。

【解决方案3】：

您可以很好地使用 EAV 模型。我们对物流应用程序做类似的事情。它是建立在.net 上的。除了表格之外，您的应用程序代码还必须正确处理对象。看看您是否可以为每个对象添加通用表。它对我们有用。

【讨论】：