Workiva/EVA项目中的属性建模设计解析：与SQL数据库的对比分析

引言

在数据建模领域，传统的关系型数据库(SQL)和新兴的属性建模(EAV)方法各有特点。本文将以Workiva/EVA项目中的属性建模设计为例，通过一个个人消费追踪应用的具体场景，深入分析两种建模方式的差异和各自的优势。

应用场景描述

我们以一个个人消费追踪应用为例，该应用需要处理来自三种不同来源的消费数据：

1. 收据照片的OCR识别结果
2. 银行账户的每日CSV导入
3. 无收据时的现金消费手动录入

应用需要满足以下核心需求：

• 允许用户修正错误数据（通过手动覆盖原始条目）
• 生成月度消费报告
• 追踪每笔消费的原始来源（包括所有手动修改记录）

SQL数据库实现方案

基础表结构设计

初始的消费表(expenses)设计如下：

CREATE TABLE expenses (
  id        INTEGER PRIMARY KEY,
  amount    REAL,
  made_at   TIMESTAMP
);

这种设计无法追踪数据来源，因此需要引入来源表(sources)：

CREATE TABLE sources (
  id        INTEGER PRIMARY KEY
);

ALTER TABLE expenses ADD COLUMN source_id INTEGER REFERENCES sources(id);

类层次结构映射

在面向对象设计中，我们可以将不同来源抽象为类层次结构：

Source (基类)
├── ManualEntry (手动录入)
├── ReceiptItem (收据项目)
└── CSVRow (CSV行项目)

在SQL中有三种常见的类层次映射方式：

1. 整个类层次使用单一表
2. 每个子类使用单独的表
3. 每个具体类使用单独的表

数据修正的实现困境

当用户需要修正错误数据时（如OCR将$8.99识别为$899），SQL实现面临两个选择：

1. UPDATE方案：直接更新错误记录

   • 优点：查询逻辑简单
   • 缺点：丢失历史记录，违反可追溯性要求

2. INSERT方案：插入新记录并标记覆盖关系

   • 优点：保留完整历史
   • 缺点：需要复杂的查询逻辑来获取"有效"数据

最终SQL方案

采用INSERT方案后，我们需要扩展数据模型：

ALTER TABLE sources ADD COLUMN overrides_id INTEGER REFERENCES sources(id);

对应的查询也变得复杂：

SELECT SUM(amount) FROM expenses e 
JOIN sources s ON s.id = e.source_id
WHERE NOT EXISTS (
  SELECT * FROM sources s2 WHERE s2.overrides_id = s.id
)
AND made_at BETWEEN '2018-01-01' AND '2018-02-01';

EVA属性建模方案

基本概念

EVA采用基于事实的三元组（实体-属性-值）模型，实际上是五元组（包含事务ID和操作类型）。在我们的消费追踪应用中，可以定义以下事实类型：

实体	属性	值类型
	is-on-receipt
	from-import
	made-at
	has-text
	has-amount
	overrides

数据表示示例

1. 收据项目(Ref-1)：

   [Ref-1, is-on-receipt, Ref-2]
   [Ref-1, has-text, "Beer $899"]
   [Ref-1, has-amount, 899.0]
   

2. 手动修正(Ref-3)：

   [Ref-3, overrides, Ref-1]
   [Ref-3, has-text, "Fixes $899->$8.99"]
   [Ref-1, has-amount, 8.99]  # 直接修改原实体的值
   

查询实现

基础月度报告查询：

[:find (sum ?amount) :where
 [?e :has-amount ?amount]
 [?e :made-at ?t]
 [(in-range? ?t ['2018-01-01' '2018-02-01'])]

EVA的独特之处在于，它通过"影子"机制处理数据更新 - 新事实不会删除旧事实，而是使其不可见但仍可查询。这种机制天然支持完整的历史追溯。

核心差异分析

1. 引用类型：

   • SQL中的外键是强类型的（特定表和列）
   • EVA中的引用是多态的，不依赖类型信息

2. 类型系统：

   • SQL需要显式定义表结构和关系
   • EVA可以通过上下文推断实体类型

3. 关系复用：

   • SQL中相同语义的关系需要在不同表中重复定义
   • EVA中的属性可以跨实体类型复用

4. 历史数据支持：

   • SQL需要额外设计来实现历史追踪
   • EVA内置完整的历史记录和时间旅行功能

结论

Workiva/EVA项目的属性建模方法提供了一种灵活的数据表示方式，特别适合需要高度动态模式、完整历史追溯和多态关系的应用场景。相比传统SQL方法，EVA在以下方面表现出色：

1. 模式演化更加灵活
2. 历史数据管理更加简单
3. 复杂关系的表达更加直观

然而，这种灵活性也带来了一定的学习曲线，开发人员需要适应不同的数据建模思维方式。对于需要严格模式约束和高性能事务处理的应用，传统SQL可能仍然是更好的选择。

通过这个消费追踪应用的例子，我们可以清晰地看到两种方法在设计理念和实现细节上的差异，为技术选型提供了有价值的参考。