数据库设计:EAV选项？

Question

这只是一个数据库概念问题:以下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     |
--------------------------------------

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

我在模型2中看到的一个好处是attribute它不包含重复项.

Answer 1

虽然如图所示是极简主义,但Model2的属性表将元数据的概念引入混合中,并带来了所有的好处.Model2还有其他优点,例如与较小行大小(Value表)相关的性能提升,但我想关注元数据概念.

即使as-is, Model2的属性表构成了所有有效属性的存储库(对于model1,需要运行排序的聚合查询来获得这样的列表).此外,原样,存储库足以引入外键约束来帮助维护数据集的完整性(模型1需要外部形式的验证存储在属性列中的值.

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

• 诸如每个属性的显示友好名称之类的信息
• 一些标志指示字段类型(数字与字符串与日期等),用于区分处理/处理
• 存储基础属性的特定值表(模型仅显示一个表,但优化/缩放有时会提示拆分表)
• 事实上,该属性可以作为自己的列存储在"值"表中(再次是一种优化形式,基本上是两个世界中最好的:EAV模型的架构的灵活性,但传统的关系模型的性能所有实体使用最多和/或最常用的属性.
• 能够重命名属性,而不会干扰主表.仅在元数据级别更改.
• 各种面向应用的语义.例如,应将特定属性作为基本搜索字段和高级搜索字段之一提供的指示符.

简而言之,属性表成为一种资源,它允许应用程序真正实现数据驱动(或更精确地说,元数据驱动).实际上,您可能也喜欢实体表,即收集与各种实体类型相关的元数据的实体表:哪些是不同的实体类型,哪些属性是允许哪种实体类型等.

现在......请注意zerkms的评论,在问题本身之下.尽管如此,EAV模型还有其缺点和挑战,因为暗示了查询的复杂性以及性能问题.然而,这些问题不应该被取消,先验,EAV:有许多用例,其中EAV是更好的方法.
假设EAV是选择,那么Model2,甚至更复杂的东西都明显优于model1.