# 数据持久化设计正反例

正例展示的是证据粒度，不是可复制的默认技术方案。对象、属性、规模、命令和恢复方式必须替换为当前项目事实。

## 正例

### 关系型存储示例

- 权威资产：当前 migration 目录中的建表与索引变更；目标 PostgreSQL 版本已记录。
- 对象：订单；租户标识和状态为不可空，状态集合由数据库约束与应用枚举共同维护。
- 访问路径：租户订单列表按创建时间倒序；索引顺序由该查询过滤与排序条件推导，并用生产等价数据的执行计划复核。
- 迁移：本次只新增空表；仅在确认无业务数据、无依赖引用时允许逆向删除，否则使用备份恢复或前向修复。
- 映射：接口状态字段映射到订单状态列，展示用总额为明确的派生字段。

### 文档存储示例

- 权威资产：当前项目的集合校验规则、索引声明和模型定义，不创建无用的 `schema.sql`。
- 对象：会话文档；消息内嵌在会话中，附件只保存对象存储引用。
- 不变量：租户键与会话标识共同唯一；单文档原子更新保证版本递增，跨文档操作通过幂等事件补偿。
- 访问路径：按租户和最近活跃时间分页；复合索引由真实查询分析证明。
- 迁移：后台分批回填新属性，读路径兼容旧文档；达到覆盖阈值并核对错误率后再停止兼容读，恢复时保留旧字段直到观察窗结束。

好在：两种方案都指出了权威资产、数据边界、不变量、访问证据、兼容窗口和恢复路径；没有把某一种存储机制冒充普适要求。

## 反例

| 数据 | 类型 | 说明 |
|---|---|---|
| 状态 | string | 存一下 |

问题：没有对象边界、所有者、权威资产、必需性、允许值、一致性、访问路径、迁移、敏感级别或验证证据，无法指导安全实现。

“所有项目都生成 schema.sql、每个 migration 都写 down、加索引即可提升性能”也是反例：它把关系型惯例当成通用事实，可能制造无效资产、数据丢失或性能退化。

### 迁移收敛反例

- 把 30 个增量脚本 squash 成新基线后直接替换——不做双库机械等价验证（列/索引/CHECK/种子数据 diff），存量库的差异要等到生产迁移才炸。
- 两个环境的服务共用一个数据库「图省事」——一侧的 mock 任务会污染另一侧的资金语义。

问题：收敛与分库的纪律都在防「看不见的差异」；省掉的验证步骤会在最贵的环境补收利息。

## 迁移到当前项目

替换存储类型与版本、权威资产路径、数据对象、属性、不变量、访问模式、容量依据、兼容窗口和恢复方式。关系型项目用真实 migration/schema 与查询计划举证；非关系型项目使用模型定义、集合/索引配置、事件或对象契约及对应的真实验证。所有结论都应能定位到当前项目资产或执行记录。