为什么使用
当你有一个实体类型，其属性可以由用户自定义时，你面临的是一个动态或灵活的数据模型设计问题。在这种情况下，传统的固定列数据库模型可能不太适用，因为预先定义所有可能的属性是不现实的。
什么场景使用
动态或灵活的数据模型设计的时候,比如一个实体的属性是多变的,不好预先创建表
什么是EAV模型
1 Entity-Attribute-Value (EAV) 模型
EAV 模型是一种常用来处理可扩展属性集的数据库设计方法。在这个模型中，你将数据存储在三个主要的列中：实体（Entity）、属性（Attribute）和值（Value）。
表设计:
- Entity 表: 存储实体的基本信息。
- Attribute 表: 存储可能的属性名称。
- Value 表: 存储实体的属性值，通常包括对 Entity 表和 Attribute 表的外键引用。
优点:
- 非常灵活，可以轻松添加或删除属性。
缺点: - 查询复杂，性能问题，数据完整性维护困难。
怎么使用
假设我们要设计一个系统，允许用户添加和管理他们自己的“产品”，其中每个产品的属性可以由用户自定义。我将使用 Entity-Attribute-Value (EAV) 模型来展示这个设计。
实体设计
- Product 表: 存储产品的基本信息。
product_id: 产品的唯一标识符（主键）。product_name: 产品的名称。
- Attribute 表: 存储可能的属性名称。
attribute_id: 属性的唯一标识符（主键）。attribute_name: 属性的名称。
- Value 表: 存储产品的属性值。
value_id: 值的唯一标识符（主键）。product_id: 引用 Product 表的外键。attribute_id: 引用 Attribute 表的外键。value: 属性的实际值。
数据库表结构
Product 表 +------------+--------------+ | product_id | product_name | +------------+--------------+ | 1 | 产品 A | | 2 | 产品 B | +------------+--------------+ Attribute 表 +--------------+----------------+ | attribute_id | attribute_name | +--------------+----------------+ | 1 | 颜色 | | 2 | 尺寸 | | 3 | 重量 | +--------------+----------------+ Value 表 +----------+------------+--------------+-------+ | value_id | product_id | attribute_id | value | +----------+------------+--------------+-------+ | 1 | 1 | 1 | 红色 | | 2 | 1 | 2 | 小 | | 3 | 1 | 3 | 500g | | 4 | 2 | 1 | 蓝色 | | 5 | 2 | 2 | 大 | +----------+------------+--------------+-------+
在这个例子中，我们有两个产品：“产品 A”和“产品 B”。每个产品都有一组属性（颜色、尺寸、重量），这些属性及其值分别存储在 Attribute 表和 Value 表中。
查询示例
要获取“产品 A”的所有属性和值，我们可以执行以下 SQL 查询：
SELECT p.product_name, a.attribute_name, v.value FROM Product p JOIN Value v ON p.product_id = v.product_id JOIN Attribute a ON v.attribute_id = a.attribute_id WHERE p.product_name = '产品 A';
这将返回“产品 A”的所有属性和对应的值。
注意事项
- EAV 模型提供了极大的灵活性，但在查询效率和数据完整性方面存在挑战。
- 对于具有大量属性或高查询要求的场景，可能需要考虑其他数据存储解决方案，如 NoSQL 数据库或 JSON/XML 列。
