避免EAV的产品属性系统

Question

我正在为产品建立一个属性系统。我遇到的问题是，不同的产品可能有非常不同的属性要求。

一些电子商务网站，如Magento使用EAV系统。由于性能问题、数据库的清洁度/复杂性/控制，我想避免这种情况。

到目前为止，我倾向于使用各种各样的桌子。例如，我可能有一个与医疗设备相关的属性表，然后是另一个用于玩具和游戏的表。任何通用属性都只属于实际的产品表。如果我确实选择了这个选项，那么我想我的产品表将有一个列来表示使用哪个属性表。

我并不是真正的数据库管理员，所以我不知道什么是最好的。我希望有人能给我一些关于良好实施的见解，或者承认我目前的思维过程是正确的。

谢谢

Answer 1

正如一位horse_with_no_name建议的那样，如果您使用PostgreSQL，我也会使用hstore，因为我认为，如果您决定需要它，可以最容易地将其转换为常规的表结构。

有几个特性使hstore对您的问题相当满意：

1)索引的速度相当快

2)您可以使用以下内容查询hstore列

SELECT p.product_name, properties->'color' As color, properties->'size'::numeric As size
     FROM products;

因此，只需将不同的产品线包装在视图中就可以进行报告了。

3) hstore的主要缺点是跟踪特定产品类型的属性，但是您可以很容易地通过PostgreSQL类型系统来弥补这一点。

如图所示：https://stackoverflow.com/questions/16092890/how-can-i-translate-a-postgresql-hstore-column-into-a-row

因此，您可以为鞋子定义一个属性类型，称为CREATE类型shoe_properties(颜色文本，大小数字)；

或者，只需使用属性类型及其相应数据类型的查找表进行编辑。然后，如果您稍后决定使用单独的表for properties方法，您的工作将很简单，只需从您的类型创建一个类型化的表，并使用popular_record将您的hstore变形为一行，以便插入到表中。

Answer 2

你的问题看上去就像一个非常普遍的模式的例子。这种模式在扩展ER建模中被称为“泛化和专门化”。它还包括对象建模中的名称“类和子类”(或“类型和子类型”)。

在设计面向对象的数据结构时，继承的概念在设计中起着关键的作用。在设计关系数据模型时，设计人员面临的现实是关系数据模型不包含继承的概念。

因此，设计人员被迫通过工作环境来实现继承，方法是设计或多或少按照继承工作方式工作的表。这种情况以前就有过研究，有些设计比较好，效果也比较好。

这些设计中有两个名为“单表继承”和“类表继承”。马丁·福勒在他的一本书中很好地展示了这两种设计。您可以在这两个网页上看到摘要：

http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html http://martinfowler.com/eaaCatalog/classTableInheritance.html

您可以根据案件的具体情况选择哪一个。

结合类表继承，有一种称为共享主键的技术。共享主键包括为子类表定义一个键，它既是主键，也是引用类表中的行的外键。这做了两件事:它强化了这些关系的一对一性质，并使相关的连接变得简单、简单和快速。

您可以在StackOverflow区域看到这种技术：

https://stackoverflow.com/questions/tagged/shared-primary-key

这三种设计或技术并不完美，它们需要应用程序程序员做一些工作。但它们能很大程度上满足一种非常普通的需求。