数据库表关系

落地入口

实际建库时先看 数据库落地执行指南，再按版本阅读各表文档。

版本关系

• v1：users
• v2：conversations、conversation_members
• v3：messages
• v5：user_devices
• v7：message_receipts

关系总览

users 1 - N conversation_members
conversations 1 - N conversation_members
conversations 1 - N messages
users 1 - N messages
users 1 - 1 user_devices
messages 1 - N message_receipts

关系说明

• 一个用户可以加入多个会话，通过 conversation_members.user_id 关联
• 一个会话可以包含多个成员，通过 conversation_members.conversation_id 关联
• 一个会话可以包含多条消息，通过 messages.conversation_id 关联
• 一个用户可以发送多条消息，通过 messages.sender_id 关联
• 一个用户有一条设备上报记录，通过 user_devices.user_id 关联，设备详情保存在 data JSON 中
• 一条消息可以有多个用户回执，通过 message_receipts.message_id 关联

版本落地顺序

users
  -> conversations + conversation_members
  -> messages
  -> user_devices
  -> message_receipts

先落地 users 后，才能建立会话成员关系。先落地会话后，消息才有归属。设备和消息回执分别服务于离线同步、精细已读等后续能力。

建表执行顺序

本项目当前 SQL 不声明数据库外键，依靠业务代码和索引保证关系正确。推荐仍按依赖顺序执行建表，方便开发和排查：

1. 执行 数据库表创建-人员，创建 users
2. 执行 数据库表创建-会话，创建 conversations、conversation_members
3. 执行 数据库表创建-消息，创建 messages
4. 执行 数据库表创建-设备，创建 user_devices
5. 执行 数据库表创建-消息回执，创建 message_receipts

外键策略

当前建表 SQL 暂不添加 FOREIGN KEY：

• 优点：本地开发、表结构迭代和数据清理更简单
• 代价：必须在 model 层显式校验用户、会话、成员、消息是否存在
• 要求：所有写入关系表的入口都必须先查询上游记录

后续如果要补数据库外键，建议在接口和数据清理逻辑稳定后再统一增加，避免开发早期被级联约束卡住。