cmr-mini/backend/docs/数据模型.md

数据模型

当前 migration 共 5 版。

1. 迁移清单

• 0001_init.sql
• 0002_launch.sql
• 0003_home.sql
• 0004_results.sql
• 0005_config_pipeline.sql

2. 表分组

2.1 多租户与入口

• tenants
• entry_channels

职责：

• 识别品牌壳
• 识别渠道入口
• 承接后续俱乐部 / 政府公众号 / H5 / 二维码入口

2.2 用户与登录

• users
• login_identities
• auth_sms_codes
• auth_refresh_tokens

职责：

• 平台级用户
• 多身份登录
• 验证码记录
• refresh token 持久化

当前身份示例：

• mobile
• wechat_mini_openid
• wechat_unionid

2.3 业务对象与配置发布

• events
• event_releases

职责分工：

• events 管业务对象身份和展示
• event_releases 管发布后的运行配置入口

关键字段：

• events.current_release_id
• event_releases.release_public_id
• event_releases.config_label
• event_releases.manifest_url
• event_releases.manifest_checksum_sha256
• event_releases.route_code

2.4 首页与入口卡片

• cards

职责：

• 支撑首页卡片
• 运营入口聚合
• tenant/channel 维度展示控制

2.5 运行态

• game_sessions
• session_results

职责：

• 固化一局游戏
• 固化该局绑定的 release
• 固化局后结果摘要

2.6 配置构建与发布资产

• event_config_sources
• event_config_builds
• event_release_assets

职责：

• 保存编辑态 source config
• 保存构建后的 manifest 和 asset index
• 保存正式 release 关联的资产清单

3. 当前最关键的关系

tenant -> entry_channel

一个 tenant 下可有多个渠道入口。

user -> login_identity

一个平台用户可绑定多个登录身份。

event -> event_release

一个 event 可有多个 release。

客户端真正进入游戏时，最终会消费其中一份 release 的 manifest。

event_release -> game_session

一局 session 必须绑定一份明确的 release。

这是当前系统最关键的配置驱动约束。

game_session -> session_result

一局结束后可有一条结果摘要。

event_config_source -> event_config_build -> event_release

这是后续配置生命周期主链：

• source 是编辑态
• build 是构建态
• release 是发布态

4. 当前已落库但仍应注意的边界

4.1 不要把玩法细节塞回事件主表

当前数据库只记录：

• 发布关系
• manifest 入口
• 结果摘要

玩法解释器仍应留在游戏客户端。

4.2 不要让历史局跟随当前 release 漂移

即使 event 后面发布新版本：

• 旧 session 仍然指向旧 event_release_id
• 旧 result 仍然对应旧 release

4.3 不要把登录态和运行态混在一起

当前已有两种 token：

• access_token
• sessionToken

后面如果加实时网关，也应继续区分。

5. 当前缺口

当前 schema 还没有这些模块：

• competitions
• registrations
• page_configs
• clubs
• client_devices
• 实时票据 / 网关票据

这些后面要按真正业务需要补 migration，不要先拍脑袋建大而全表。