数据库设计策略：电子商务系统上的产品表（EAV，类表继承或具体表继承）

Question

我的电子商务系统将有5种基本类型的产品：

1. 手机
2. 计算机
3. 鞋
4. 衬衫
5. 默认（无特定属性）

每个人都有相关的特定属性......

我做了什么（类表继承）：

Product
   Id
   Name
   Sku
   Price
   ...   

Shoe
   ProductId 
   Size
   Color
   ...

Computer
   ProductId
   Memory
   Processor
   ...

您对该设计有何看法？我认为这不是一个好主意，因为它会使代码变得复杂，例如：

- 系统显示页面中的所有产品

- 客户选择鞋子

- 我有ProductID并且必须检查它是手机还是电脑或鞋......

我不知道，也许我在想错...

我认为EAV根本不是一个好选择...

你们的想法是什么？

由于

Answer 1

在数据库中至少有三种表示类继承的方法

• Single Table Inheritance：整个继承树中的所有属性都存储在一个表中，并且有一个描述行类型的专用列。这意味着将有许多未使用的列，因此只有当子类共享大多数属性时，此方法才有意义。
• Class Table Inheritance：树中的每个类都保存在一个单独的数据库表中，该表仅存储特定于该类的属性。这意味着，为了获取对象，您必须在表示继承树中祖先的表中进行连接。
• Concrete Table Inheritance：每个具体类都有一个单独的数据库表，但存储了给定类所需的所有属性，包括继承的属性。这意味着您不必加入，但另一方面您无法升级（例如，当您查询产品时，您将看不到任何鞋子）。

这些方法中的每一种都有利有弊，这是你必须做出的权衡。

另一方面，使用继承来表示产品类型意味着每次引入新的产品类型时都必须修改代码和数据库模式。如果类型将发生很大变化并且每种类型没有太多逻辑关联，那么使用单个（producId，key，value）产品属性表可能会更好。这不是一个漂亮的数据库设计，但在这种情况下会变得更加实用。

Answer 2

你的对象设计很好。

但是，我建议使用单表继承（如Adam所述）并避开EAV。如果您的RDBMS支持XML类型并且您担心存储所有可归零字段，请将所有可选数据放在单个XML列中。然后，模式验证将确保您不会尝试使用一双鞋等来存储处理器类型。

为每种产品类型添加额外字段就像更新该特定产品的架构一样简单。

Answer 3

您的设计是今天的正确标准。它被称为规范化，将对象分解为更小的对象表。这是关系数据库的全部目的。我会留在你正在的道路上