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

Question

我有一个模型，它拥有许多具有多个值的属性，这些值要么代表列表，要么代表其他模型。我的研究使我考虑使用Entity-Attribute-Value design 来代表此类，但我看到更有知识的人比建议更沮丧。

让我印象深刻的是这条评论：

简而言之，当您的属性列表经常增长时，或者当它太大以至于如果您将每个属性都设为列时，大多数行将被大部分 NULL 填充时，EAV 很有用。在该上下文之外使用时，它会成为一种反模式。

by Karl Bielefeldt.

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

• 身份证
• 创作者
• 修订历史记录
• 部门
• 参考文献
• 资金（可选、可变/不固定）
• cmets
• 目标（段）
• 范围（段落）

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

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

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

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

对于诸如references 和funding 之类的可变/非固定模型，我计划使用中介表将student_form 连接到这些“列表”以标准化DB：

• 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 模型更好地为您服务。我不知道它是否完全标准化，我不确定它是否必须如此。