具有多个属性的模型的EAV数据库设计（其他模型）

Question

我有一个拥有许多属性的模型，这些属性具有多个值，可以是列表或其他模型的表示。我的研究让我考虑用Entity-Attribute-Value design代表这样的人，但我看到更多知识渊博的人比建议更多的沮丧。

一个坚持我的是这个评论：

  

简而言之，当您的属性列表经常增长时，或者如果您将每个属性都设为列时大多数行将填充大多数NULL，EAV非常有用。当在该背景之外使用时，它变成反模式。

by Karl Bielefeldt

基本上我的模型是student_report。它具有以下基于实际形式的属性：

• ID
• 创建者
• 修订历史
• 部门
• 引用
• 资金（可选，可变/不固定）
• 评论
• 目标（段落）
• 范围（段落）

creator，revision history，department，references，funding和comments是此表单依赖的其他模型。

我的初步计划是仅使用以下内容创建student_report：

• ID
• 创作者身份
• 目标
• 其他段落式内容

而其他人：revision history，department，references，funding和comments将拥有外键student_report_id。

对于references和funding等变量/非固定模型，我计划使用中介表将student_form连接到那些规范化数据库的“列表”：

• student_report

  | id | name            |
  |----|-----------------|
  | 1  | Abraham Smith   |
  | 2  | Betty Gladstone |
  | 3  | Chen Hong       |
  

• references

  | id | name         |
  |----|--------------|
  | 1  | Reference 1  |
  | 2  | Reference 2  |
  | 10 | Reference 10 |
  

• report_references

  | user_id | reference_id |
  |---------|--------------|
  | 1       | 2            |
  | 1       | 3            |
  | 2       | 10           |
  

我建议的解决方案是否足够？这将是一个小规模的项目，我怀疑这将需要每天数百次使用。

Answer 1

EAV可帮助您在数据模型未被充分理解时捕获数据。它允许您跳过数据分析并提出一种适应性强的单一设计，无论数据的实际结构如何，它都能处理大量数据。

但是有一个缺点。由于您尚未在存储时分析数据，因此您必须在检索数据时将其分析并将其转换为有用的数据，例如报告或数据提取。否则你的结果毫无意义。在某些情况下，这种下行空间可能比您之前经历的好处大得多。

在您的情况下，您似乎很好地理解了要存储的属性以及这些属性的语义。根据意外情况，属性列表也不太可能必须扩展。

所以我建议你避免使用EAV，而是专注于如何从属性中组合关系。关系只是属性的集合，以某种方式组合在一起，既有益又有用。如果您愿意，可以阅读有关此主题的书籍。

在SQL中，表表示关系。表有行，表示元组。表具有表示属性的列。行和表的交集提供了可以存储值的位置。在！NF中，每个位置都存储一个“简单”值。

你的设计看起来很不错。我认为它会比EAV模型更好地为你服务。我不知道它是否完全正常化，我不确定它是否必须。