sql - 我应该使用 EAV 数据库设计模型还是大量表格

Question

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

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 设计的选项更好、更容易且性能更好。

Answer 1

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

但是还有其他方法。您可以考虑使用具有扩展数据的 XML 字段，或者，如果您使用的是 PostgreSQL 9.2，则可以考虑使用 JSON 字段(尽管 XML 更易于搜索)。这将为您提供更大范围的可能搜索，而无需 EAV 的麻烦。权衡是模式实现会更难。