实体 - 属性 - 值表设计

Question

我目前正在为电子商务平台的产品部分设计数据库结构.它需要以这样的方式设计,使得可以销售具有无限多个不同属性的无限数量的不同类型的产品.

例如,笔记本电脑的属性可以是RAM,屏幕尺寸,重量等.书的属性可以是作者,ISBN,出版商等.

似乎EAV结构最合适.

• 选择一个产品
• 产品属于属性集
• 属性集包含属性x和y
  • 属性x是数据类型datetime(存储在attribute_values_datetime中的值)
  • 属性y是数据类型int(存储在attribute_values_int中的值)
• 每个属性定义表示类型(i,e,x具有列类型 - > datetype)

假设上述情况,我是否可以将选择加入attribute_values_datetime表以获取正确的数据而不获取结果集并在表已知的情况下构建第二个查询？构建这种类型的查询是否会有很大的性能损失,或者下面的内容会更合适(尽管功能较少)

• 选择一个产品
• 产品属于属性集
• 属性集包含属性x和y
  • 属性x是数据类型datetime,但在attribute_values中存储为TEXT
  • 属性y是数据类型int,但在attribute_values中存储为TEXT

Answer 1

我将就这个问题的大多数评论提出相反的意见.虽然EAV是因为所有这些原因你可以在SO和DBA.SE以及其他地方找到多次彻底解释的原因,但是有一个非常常见的应用,其中大多数EAV错误的东西在很大程度上是无关紧要的(很少)EAV的优点是非常密切相关的.该应用程序是在线产品目录.

EAV的主要问题是它不会让数据库做它真正擅长的事情,这有助于通过将它们安排在模式中来为不同实体的信息的不同属性提供适当的上下文.拥有模式可以在访问,解释和实施数据完整性方面带来许多优势.

关于产品目录的事实是产品的属性几乎完全与目录系统本身无关.产品目录系统(最多)具有产品属性的三件事.

1. 以下列形式向最终用户显示列表中的产品属性:{attribute name}:{attribute value}.

2. 在比较网格中显示多个产品的属性,其中不同产品的属性相互排列(产品通常是列,属性通常是行)

3. 根据特定属性/值组合推动某些事物的规则(例如定价).

如果你的系统所做的都是回流信息,这些信息在语义上与系统无关(那么这个信息的模式基本上没有用.事实上,模式会妨碍在线产品目录,特别是如果您的目录中有许多不同类型的产品,因为您总是需要重新进入模式以修改它以允许新的产品类别或属性类型.

由于它的使用方式,即使产品目录中属性值的数据类型也不一定(非常重要).对于某些属性,您可能需要施加约束,例如"必须是数字"或"必须来自此列表{...}".这取决于属性一致性对您的目录的重要程度以及您希望实现的详细程度.看看几家在线零售商的产品目录,我认为大多数人都准备在简单性方面进行权衡.

是的,EAV是邪恶的,除非它不是.