Mysql 数据库设计：EAV选项？

这只是一个数据库概念问题：以下EAV模型的优缺点是什么

型号1:

TABLE: attribute_value
======================================
| id | fk_id | attribute | value     |
======================================
| 1  | 10    | FName     | John      |
| 2  | 10    | Lname     | Doe       |
| 3  | 55    | FName     | Bob       |
| 4  | 55    | Lname     | Smith     |
--------------------------------------

TABLE: attribute
==================
| id | attribute |
==================
| 1  | FName     |
| 2  | Lname     |
------------------

TABLE: value
=====================================
| id | attribute_id | fk_id | value |
=====================================
| 1  | 1            | 10    | John  |
| 2  | 2            | 10    | Doe   |
| 3  | 1            | 55    | Bob   |
| 4  | 2            | 55    | Smith |
-------------------------------------

型号2:

TABLE: attribute_value
======================================
| id | fk_id | attribute | value     |
======================================
| 1  | 10    | FName     | John      |
| 2  | 10    | Lname     | Doe       |
| 3  | 55    | FName     | Bob       |
| 4  | 55    | Lname     | Smith     |
--------------------------------------

TABLE: attribute
==================
| id | attribute |
==================
| 1  | FName     |
| 2  | Lname     |
------------------

TABLE: value
=====================================
| id | attribute_id | fk_id | value |
=====================================
| 1  | 1            | 10    | John  |
| 2  | 2            | 10    | Doe   |
| 3  | 1            | 55    | Bob   |
| 4  | 2            | 55    | Smith |
-------------------------------------

---

我在模型2中看到的一个好处是

属性

不包含重复项。

对于模型2，您可以在属性id上强制使用外键，并确保只有定义的属性才能进入表

---

同样对于模型2，您可以使用更快的查询来获取具有特定属性ID的值，因为如果您使用外键（索引），查询速度将更快。

尽管如图所示是最简单的，但是模型2的属性表将元数据的概念引入了混合中，并从中获得了所有好处。Model2还有其他优点，例如与较小的行大小（值表）相关联的性能提升，但我想重点介绍元数据概念

即使是Model2的属性表也构成了所有有效属性的存储库（model1需要运行排序的聚合查询才能获得这样的列表）。同样，存储库足以引入外键约束，以帮助维护数据集的完整性（对于模型1，需要对存储在属性列中的值进行外部形式的验证）

通过一些简单的添加，属性表可以成为一个多功能的存储库，可用于各种目的

• 信息，例如每个属性的显示友好名称
• 一些标志指示用于区分处理/处理的字段类型（数字、字符串、日期等）
• 存储基础属性的特定值表（模型仅显示一个表，但优化/缩放有时会提示拆分表）
• 属性可以作为自己的列存储在“值”表中（这也是一种优化形式，本质上是两全其美：EAV模型模式的灵活性，但传统关系模型对于所有实体使用最多和/或最常见的属性的性能
• 在不干扰主表的情况下重命名属性的能力。仅在元数据级别进行更改
• 各种面向应用程序的语义。例如，指示特定属性应作为基本搜索字段和高级搜索字段之一提供

简而言之，属性表成为一种资源，它允许应用程序真正由数据驱动（或者更准确地说，由元数据驱动）。实际上，您也可能喜欢实体表，即收集与各种实体类型相关的元数据的表：哪些是不同的实体类型，哪些属性允许用于哪个实体类型等

---

现在…一定要注意问题本身下面zerkms的评论。尽管EAV模型有很多优点，但它也有一些缺点和挑战，这暗示了查询的复杂性，还有性能问题。但是，这些问题不应该先验地取消EAV的资格：在很多用例中，EAV是一种更好的方法。
假设EAV是模型2的选择，或者甚至是稍微复杂一点的东西都比模型1优越。

在概念层面上，这两个模型实际上是相同的。您只是用ID号替换了字符串。仅此而已

就外键而言，如果愿意，可以在模型1中的“属性”上施加外键约束

---

就正反两方面而言，EAV的这两种实现实际上没有什么区别。两者都适用。

缺点：EAV真的很难优化。过一段时间，你会陷入无法编写的查询中，因此它们工作得很快。mjv-模型2仍然被认为是EAV吗？@StackOverownewbie-是的，最明确地说使其成为EAV的关键概念是，“主”表（所示模型中的“值”表）捆绑了所有3个元素：实体（fk_id）、属性（属性_id）和值。属性恰好作为一个[数字]存在于其中id，而不是model1的属性列中看到的一些文本，但这一事实肯定不会消除设计的EAV特性。