三大数据库对比
三个维度互不冲突，可以叠加
- 嵌入式数据库：部署形态（嵌入设备、资源受限）
- 实时数据库：时间约束（定时限制、截止时间 deadline）
- 主动数据库：行为模式（自动触发、ECA规则）
一、核心定义 & 标志性特征
1. 嵌入式数据库（Embedded Database）
✅ 核心关键词：嵌入性、资源受限、轻量化 数据库作为程序库链接进应用，不是独立服务；运行在嵌入式设备（单片机、ARM、车载、工控板）。 关注点：体积小、可裁剪、低内存、本地运行、无需独立部署。
不一定具备实时性！ SQLite 是典型嵌入式数据库，但不满足实时数据库的定时限制，读写时延不可预测。
典型产品：SQLite、Berkeley DB、eXtremeDB（嵌入式实时数据库，二者叠加）
2. 实时数据库 Real-Time Database（RTDB）
✅ 核心关键词：定时限制、截止时间、时延可预测 事务正确性 不只看逻辑结果，还要看是否在规定时间内完成。
- 普通数据库：尽力执行，快慢无所谓；
- 实时数据库：超过截止时间，事务直接判定失败。 支持事务优先级抢占、区分硬实时/软实时；追求最坏时延有上界。 适用：自动驾驶、工业控制、电力调度。
可以部署在服务器，也可以是嵌入式实时数据库（嵌入式+实时两者叠加）
3. 主动数据库 Active Database
✅ 核心关键词：主动机制、ECA规则（事件-条件-动作） 普通数据库是被动的：外部程序发起查询/修改； 主动数据库可以自动响应事件，无需应用轮询。 标准模型 ECA：ON 事件 IF 条件 THEN 动作 例子：温度写入数据库（事件）→ 如果温度＞100℃（条件）→ 自动触发报警（动作） 数据库触发器就是最简单的主动机制。
重点区分： 实时数据库关心「多久之内做完」； 主动数据库关心「满足条件自动做」。
二、
| 对比维度 | 嵌入式数据库 | 实时数据库 | 主动数据库 |
|---|---|---|---|
| 核心本质 | 部署形态：内嵌于应用程序 | 事务约束：定时限制（时间deadline） | 运行模式：事件驱动、自动响应 |
| 设计目标 | 适应资源受限嵌入式硬件 | 保证操作时延可预测，必须时限内完成 | 数据变化时自动执行预设动作 |
| 标志性机制 | 代码可裁剪、低资源占用 | 事务优先级调度、超时终止事务 | ECA（事件-条件-动作）规则 |
| 典型考题关键词 | ARM、单片机、车载、本地小型存储 | 定时限制、截止时间、硬实时、时延可预测 | 触发器、自动告警、事件触发、ECA |
| 是否可以相互叠加 | 可以；存在「嵌入式实时数据库」 | 可以；实时数据库也能内置主动规则 | 可以；三者可同时具备 |
| 反例区分 | SQLite（嵌入式，但非实时） | 普通服务器实时数据库（实时，但不属于嵌入式） | MySQL触发器（具备简单主动能力，但不是实时数据库） |
三、极易混淆
坑1：嵌入式数据库 ≠ 实时数据库
❌ 错误理解：只要跑在板子上就是实时数据库 ✅ 正确：嵌入式只是部署位置；实时要求时延有严格上限、定时限制。 SQLite广泛用于嵌入式设备，但不属于实时数据库，Flash读写抖动大，时延不可预测。
坑2：实时数据库 ≠ 速度快
❌ 错误：读写快就是实时 ✅ 正确：实时 = 执行时间可预测（有上限） 哪怕平均速度一般，但最坏情况不会超时； 很多高速数据库平均很快，但偶尔卡顿，依然不属于实时数据库。
坑3：主动数据库 ≠ 实时数据库
主动数据库关心要不要自动执行； 实时数据库关心必须在多久内执行完。 一条ECA规则可以没有时间限制；实时事务也可以没有自动触发逻辑。
四、
1. 简述实时数据库“定时限制”
实时数据库中，事务正确性不仅依赖逻辑结果正确，还要求事务必须在预先定义的截止时间（时限）内完成；若超出定时限制，即使逻辑运算无误，事务也判定失败。嵌入式控制系统任务周期性运行，数据库操作时延不可预测会造成控制任务超时失效，因此需要定时限制保障系统实时可控。
2. 主动数据库 ECA 规则
主动数据库采用**事件(Event)-条件(Condition)-动作(Action)**模型：当指定事件发生，系统评估条件；条件成立，则自动执行对应的动作，使数据库具备主动响应能力，不再被动等待应用程序调用。
五、
- 智能手表使用SQLite存储运动数据 → 嵌入式数据库
- 工业PLC，每10ms读取状态库，超时则放弃本次采样 → 实时数据库（嵌入式实时数据库）
- 监控系统：压力数据入库，超过阈值自动推送告警 → 主动数据库
注意：本文归作者所有，未经作者允许，不得转载
