一、普通记账 vs 礼账：数据模型的本质区别
普通记账App的数据模型非常简单：
记录（金额、分类、时间、备注）统计时只需要按时间或分类汇总即可。
但礼账完全不同。礼账要回答的问题是：
- “张三累计给了我多少钱？”
- “我累计给张三多少钱？”
- “我和张三之间的净额是多少？”
这需要的是双向关系数据模型。
二、核心表结构
简记往来的数据库设计围绕两张核心表展开：
联系人表（contacts）：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 主键 |
| book_id | string | 所属账本 |
| name | string | 标准姓名 |
| tags | array | 标签（同事/朋友/亲戚） |
| created_at | timestamp | 创建时间 |
记录表（records）：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 主键 |
| book_id | string | 所属账本 |
| contact_id | string | 关联的联系人ID |
| type | enum | receive（收礼）/ send（送礼） |
| amount | number | 金额 |
| date | string | 日期 |
| note | string | 备注 |
| created_by | string | 录入人 |
| created_at | timestamp | 创建时间 |
两张表通过contact_id关联。一个联系人可以有多个记录（收礼和送礼）。
三、双向关系的存储方式
关键问题是：如何用一张表存储“双向关系”？
答案是：用type字段区分方向。
type: 'receive'表示“张三给了我钱”type: 'send'表示“我给了张三钱”
查询时，按contact_id聚合，分别统计receive和send的总金额，相减得到净额。
SELECTcontact_id,SUM(CASEWHENtype='receive'THENamountELSE0END)astotal_receive,SUM(CASEWHENtype='send'THENamountELSE0END)astotal_sendFROMrecordsWHEREbook_id=?GROUPBYcontact_id这就是差额统计的底层逻辑。
四、索引优化方案
6.8万用户、62万笔记录，查询速度怎么保证？
核心索引：
-- 按账本+联系人查询记录CREATEINDEXidx_records_book_contactONrecords(book_id,contact_id)-- 按账本+日期查询CREATEINDEXidx_records_book_dateONrecords(book_id,date)-- 按账本+类型统计CREATEINDEXidx_records_book_typeONrecords(book_id,type)实际测试中，最复杂的查询（按账本聚合所有联系人的收送礼统计）响应时间稳定在200ms以内。
五、扩展性考虑
这套数据模型还支持几个扩展场景：
- 多账本：通过
book_id隔离，每个账本独立 - 多人协作：通过
created_by记录录入人 - 数据导出：直接导出
contacts和records的联表查询结果
设计数据模型时想清楚“要回答什么问题”，比一开始就追求“大而全”更重要。简记往来的数据模型从一开始就围绕“人与人的差额”这个核心问题设计，后续所有功能都是在此基础上扩展的，没有做过大的重构。
