目录
1. 实战场景
从实战进行探讨以及深入：
事因是同事给我创建表结构的时候，以如下这种方式进行创建：
看到这张表的结构可能会思考：
为啥设备的部件值（日期、数值、字符串）为啥要单独弄三张表，不直接弄成一张部件表去存储呢？？？
后续得到的回复如下：
部件表（part_info）是用于定义某一种部件的，与设备表（device_info）是多对多的关系（device_info_part），每种部件有自己的属性（part_prop），我们定义值的时候可以定义设备-部件-属性的值（prop_value_xxx），保留值类型而不是全部用字符串存储是因为方便筛选排序等等的业务，这种设计参考的是 EAV 模式。如果把部件、属性、部件属性值整合为一个设备部件属性值表，也是可以的，这样虽然重复项与值很多但是结构上简单了
2. 基本知识
EVA（Entity-Value-Action）模式 是一种用于处理数据和业务逻辑的一种架构设计模式
数据模型分为三部分：
- Entity（实体）：代表一个现实世界的对象或者概念，通常与数据库中的表或记录对应
- Value（值）：与实体相关的属性或数据值，这些值表示了实体的状态
- Action（动作）：实体上执行的操作或行为，通常是对实体值的修改或操作
这种模式旨在解耦实体、值和行为，使得系统更加灵活，易于扩展和维护
EVA 模式 与 传统数据库模型对比
| 特性 | EVA模式 | 传统模型 |
|---|---|---|
| 结构 | 三部分：实体（Entity）、值（Value）、动作（Action） | 一般是实体-属性的结构，重点是表和字段的映射关系 |
| 数据表示 | 每个数据值与实体和动作分开，数据可以有多版本（历史） | 数据通常是单一版本的实体和属性 |
| 适用性 | 适合频繁变化的业务场景，能够动态记录数据变动的历史 | 适用于较稳定、变化较少的业务数据 |
| 灵活性 | 高灵活性，可以轻松扩展新的实体或操作，支持历史版本存储 | 较低的灵活性，扩展新属性可能需要改变表结构 |
| 复杂度 | 复杂，适用于需求多变的系统 | 较简单，适合需求稳定的系统 |
| 数据一致性 | 保证操作历史，可以根据历史恢复数据状态 | 传统的数据库操作通常无法追溯历史，数据更新直接覆盖 |
| 性能 | 可能因记录历史而影响性能，但可以通过优化查询提升 | 高性能，特别是在数据量较大时，适用于批量操作 |
其优缺点可见如下：
优点：
- 支持动态变化：EVA模式能够应对频繁的业务变化，通过记录不同版本的属性值和操作历史，可以灵活适应变化
- 历史追溯：通过将“值”与“操作”分离，可以实现数据的历史追溯。对于需要审计或数据回溯的场景，特别有效
- 解耦：实体、值和动作分离，可以方便地进行扩展或修改，例如可以新增一个实体类型，而不必修改原有的表结构
缺点：
- 实现复杂：因为需要维护实体、值和动作的关系，因此模型比传统模型复杂，开发和维护成本更高
- 性能瓶颈：对于数据量大的系统，EVA模式可能会引入性能问题，特别是涉及到历史数据时，查询可能会变得非常复杂和耗时
- 数据冗余：由于每次操作都可能产生新的记录，导致数据冗余，可能会导致存储空间浪费
3. 应用场景
传统数据库模式适用于以下场景：
-
数据稳定，不经常变化的业务场景：如果数据的结构和内容变化不大，传统的实体-属性（表和字段）的关系模型更加高效和简单
示例：一个简单的用户信息管理系统，用户数据（如姓名、年龄、性别等）变化较少，使用传统的关系型数据库模型即可满足需求 -
性能要求高，数据量大且操作简单的系统：对于需要处理大量数据和高频率查询的系统，传统模式通常能提供更好的性能，尤其在查询和批量更新时，避免了多次插入和复杂的历史数据记录
示例：一个大规模的电子商务平台，需要频繁查询和更新商品库存信息，这种场景下传统的数据库设计会比EVA模式更合适 -
对历史追溯要求不高的系统：如果不需要对数据的历史进行追溯或审计，传统的数据库设计更为简单直观
示例：一个商品销售系统，只需要记录商品的当前状态，不关心商品的价格变动历史
EVA模式适用于以下几种场景：
-
审计日志系统：对于需要记录每次操作的场景，如财务系统、用户管理系统等，EVA模式可以很好地记录每次数据变动，并提供完整的历史记录
示例：在一个银行系统中，每次用户账户余额的变动（存款、取款等）都可以通过EVA模式记录下来，确保所有操作都有详细的记录，并且可以在任何时候恢复到某个历史状态 -
配置管理系统：在配置管理中，不同版本的配置文件可能需要历史追溯，这时EVA模式可以通过记录每次配置变动的值和相关操作，帮助管理不同版本的配置
示例：对于一个云服务平台，管理员需要对不同的服务配置进行修改并记录修改历史，EVA模式可以帮助实现这一需求 -
动态、频繁变化的业务场景：当业务需求和数据模型频繁变化时，EVA模式通过分离实体、值和操作，能在不影响其他部分的情况下进行灵活的扩展
示例：一个商品库存管理系统，其中商品的属性（如库存数量、价格等）可能会经常变动，并且需要追溯历史记录 -
事件源架构（Event Sourcing）：EVA模式是事件源的一种实现方式，事件源架构通过保存每一次操作或事件（Action）来重建应用状态。
示例：在一个电子商务平台中，EVA模式可以用来记录用户的每个订单操作（如下单、支付、发货等），通过这些操作（事件）重建用户的订单状态