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

Question

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

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

经过一些分析,我发现这个设计实际上是EAV模型,我读到人们通常不推荐这种设计.
似乎所有东西都需要动态的SQL查询.

这是一种方式,我现在正在看它.

我看到的另一种方式可能被称为很多工作方式,但如果它更好,我想去那里.制作桌子

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接口,以10k rpm旋转？" 你在EAV中的查询会很痛苦.如果你想支持这样的查询,EAV就会出局.

然而,还有其他方法.您可以考虑使用扩展数据的XML字段,或者如果您使用的是PostgreSQL 9.2,则可以考虑使用JSON字段(但XML更容易搜索).这将为您提供更大范围的可能搜索,而不会出现EAV的麻烦.权衡将是模式执行会更难.