【问题标题】:Database Design: how to avoid EAV? [duplicate]数据库设计:如何避免 EAV? [复制]
【发布时间】:2011-05-10 16:37:14
【问题描述】:

可能重复:
Database Design: to EAV or not to EAV?

我正在建模车辆信息。车辆可以有 0 个或多个“设备”(例如发动机、车轮、扰流板、CD 播放器等)。一个设备可以有 0 个或多个“属性”(例如,发动机的“燃料类型”可能是“柴油”)。

我事先不知道这些设备将是什么(它们将由用户定义),更不用说这些未知设备的属性。

所以,现在对我来说是使用 EAV 的诱惑。我走错路了吗?我担心我必须做这样的事情:找到所有燃料类型为柴油等的车辆。对我来说听起来很痛苦。

如有需要,对替代方法有何建议?

【问题讨论】:

  • 它应该对实体做什么?搜索?过滤?排序?是否可以创建适合所有表格的静态表格集(每个实体一个表格)?
  • 我们已经列出了 200 多种可能的设备。您是否建议使用 200 多张桌子?那么主表的相关“属性表”呢?例如,一个equipment_engine 表和一个相关的equipment_engine_attribute 表?
  • 我不知道你是否可以避免它,但某些属性可能足够常见,以至于它们可以与 EAV 分开存储(即:引擎、门、*)。
  • @Aaron - 这个问题比最初发布的更明确,因为我现在对需求有了更清晰的了解。第一个问题假设只有少数设备具有一些高级已知的属性,这个问题假设不知道设备或其属性。更大的问题,IMO——我想对可能的解决方案有新的看法。

标签: mysql sql database-design data-modeling


【解决方案1】:

经验法则是:

  1. 如果键/值对可能是 where 子句的一部分或通过 sql 进行操作,则它可能应该是表中的适当类型列,而不是 eav 存储中。

  2. 如果经常组合多个键/值对,它们可能属于单独的表。

【讨论】: