数据库设计：EAV 选择？

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

Model 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     |
--------------------------------------

Model 2:

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 |
-------------------------------------

我认为 Model 2 的一个好处是attribute不包含重复项。

尽管如图所示是极简的，但 Model2 的属性表引入了以下概念：元数据融入其中，并从中获得所有好处。 Model2 还有其他优点，例如绩效提升与较小的行大小（值表）相关，但我想重点关注元数据概念。

Even as-isModel2的属性表构成所有有效属性的存储库（对于 model1，需要运行某种聚合查询才能获得这样的列表）。还有，还有as-is，存储库足以引入外键约束帮助维护数据集的完整性（对于模型 1，需要对属性列中存储的值进行外部形式的验证。

通过一些简单的添加，属性表可以成为一个多功能的存储库，可用于各种目的。例如，该表可能包括以下一些内容

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

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

现在...请注意来自的评论zerkms，位于问题本身下方。尽管有这么多优点，EAV 模型也有其缺点和挑战，正如所暗示的查询的复杂性以及性能问题。然而，这些担忧不应先验地取消 EAV 的资格：在许多用例中，EAV 是更好的方法。
假设选择 EAV，那么 Model2，甚至稍微复杂一点的东西肯定优于 model1。