游戏数据分类与建模

Category

database / 数据建模。节点定位：先回答「这到底是哪一类状态」再谈表——运行时临时状态、长期资产、派生查询数据、审计与归档的分界，是本树其余节点的总纲。

Definition

数据库设计真正难的地方，不是表怎么建，而是状态怎么分。游戏里的“数据”看起来都要存下来，但它们的性质差异其实非常大：有的是高频临时状态，有的是长期资产，有的是为了检索方便的派生副本，有的是为了审计和恢复保留下来的操作记录。把这些完全不同的数据长期塞进同一种模型里，系统很快就会失去弹性。

所以讨论数据建模时，第一步永远不是建表，而是先回答“这到底是哪一类状态”。

Problem

平时「能存下来」不代表建模合理，建模质量只在迁移、补偿、回滚、归档这些时刻现形。最贵的两类错账：运行时临时状态和长期资产混在一起——实时链路被资产拖慢、资产被高频写入污染；派生副本反向变成事实来源——排行副本当战力真相、报表聚合做线上裁决。先分状态类别、定权威源，再谈表结构。

游戏里常见的数据类型并不一样

比较常见的分类方式，通常至少包括：

• 运行时临时状态
• 长期资产状态
• 派生查询数据
• 审计与操作日志
• 分析与归档数据

这些数据之所以要区分，不是为了概念完整，而是因为它们对一致性、查询方式、保留周期和恢复能力的要求完全不同。

运行时临时状态为什么不能和长期资产混在一起

房间状态、场景对象、战斗过程、匹配上下文这类数据，往往变化快、生命周期短、实时性要求高。它们更关心的是当前是否能快速推进，而不是被复杂查询和长期留存。

角色资产、背包、订单、任务进度、货币余额这类长期状态则不同。它们更关心的是：

• 最终是否正确
• 是否能审计
• 是否可回滚和补偿
• 跨版本和跨区服迁移时是否可解释

把两者长期绑在一起，通常会得到一种最糟糕的中间态：实时链路被长期资产拖慢，长期资产又被实时链路的高频写入和临时结构污染。

派生数据和源数据必须分清

很多系统里最容易做坏的一点，就是为了查询方便，慢慢让派生数据反向变成了事实来源。例如：

• 排行榜副本被当成玩家最终战力真相
• 邮件展示副本被当成奖励权威状态
• 报表聚合结果被拿来做线上裁决

更稳妥的做法是，明确区分：

• 谁是权威源数据
• 谁是为了性能和查询效率生成的派生副本
• 副本何时更新，失效时如何重建

只要这个边界不清，后面排障、补数和迁移都会越来越痛苦。

数据建模首先要围绕哪些问题

谁拥有这份状态

这份数据由哪个系统最终负责，它是不是单一真相源，决定了后面更新链路和恢复方式。

它被怎样读取

是按玩家主键读，按时间区间查，还是需要复杂聚合，这会直接影响存储结构是否合理。

它需要保留多久

有些状态只在本局有价值，有些要陪玩家整个生命周期，还有些只需保留作审计和归档。

它出错后的代价有多大

资产错误、支付错单、奖励重复和短时查询延迟，代价完全不同。建模时如果不先看失败代价，后面成本一定会错配。

为什么很多问题会在迁移和恢复时才暴露

平时系统能跑，不代表建模合理。真正能暴露建模质量的，往往是这些时刻：

• 合服和跨区迁移
• 资产补偿和数据修复
• 回滚和审计追责
• 冷热分层和归档重建

如果一到这些场景，团队就发现状态来源不清、字段语义混乱、派生链路不可重建，说明问题从一开始就不在数据库产品，而在建模本身。

常见误区

最常见的错误，是把“能存下来”当成“建模完成”，不去区分运行时状态、长期资产和派生数据。第二类错误，是查询怎么方便就怎么建，长期没有明确权威数据源。第三类错误，是只为当前功能建模，不为迁移、恢复、审计和归档预留结构，结果系统一到长线运营阶段就开始失控。

Used By

任何带服务端的项目的数据评审：新系统定数据分类与权威源（谁拥有、怎么读、留多久、出错代价四问）；长线项目在合服、补偿、回滚前做建模体检。验收方法：拿一单真实资产争议工单，看四类数据的来源与恢复路径是否都答得出。

Related

关系链：状态分类 → 权威源指定 → 存储选型（02）→ 事务与一致性分层（03）→ 生命周期治理（04）。逐段回答「为什么需要下一个」：分类之后要定权威源，派生副本必须有可指认的源头；定了权威才谈选型，失败代价决定存储分层；选型定了才谈事务边界与扩展；前三步做完，生命周期治理才有台账可写。下游：cache 子树（读加速层的边界）。

Reference

本页为工程经验归纳，无单一外部出处。