mysql eav_mysql – 数据库设计：EAV选项？

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

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

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

> info,例如每个属性的显示友好名称

>一些标志,指示字段的类型(数字与字符串与日期等),用于区分处理/处理

>存储基础属性的特定值表(模型仅显示一个表,但优化/缩放有时会提示拆分表)

>该属性可以作为自己的列存储在“值”表中(再次是一种优化形式,实质上是两全其美：EAV模型的架构灵活性,但传统关系模型的性能)对于所有实体中使用最多和/或最常见的属性.

>能够重命名属性,而不会干扰主表.仅在元数据级别更改.

>各种面向应用程序的语义.例如,应将特定属性作为基本搜索字段和高级搜索字段之一提供的指示符.

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

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