前一篇主要是从产品内容角度进行数据的逻辑分类，现在主要是从数据存储方法角度进行数据的物理分类。
一般也称之为扫档数据。例如当前服务器玩家的基本信息表： ID，玩家角色名字，玩家性别，玩家等级，玩家门派....... 101，角色1，m，2，3..... 102，角色2，f，3，4...... 103，角色3，m，10，5.... .......
之所以称为快照型数据，是因为这些数据是实时变化，我们通常只能获取到某个时间点的数据。以玩家等级为例，因为低等级的新增玩家升级比较快，现在全服玩家的等级分布与一分钟前玩家的等级分布是不同。而现实情况的数据分析并不需要到每时每刻。通过某个快照，可以详细分析这个时间点的玩家属性与行为；而综合各个时间点的快照，则可以反映玩家属性与行为的变化趋势。
也可称为事件驱动型数据，因为玩家行为触发某个事件，导致服务器打下一条详细的记录。以任务表为例如下： 时间戳、玩家角色ID、玩家等级、玩家门派、任务ID、任务状态（接受/完成/失败/放弃）、任务奖励 2012-01-08 00:00:00，101，2，3，1，1（接受）， 2012-01-08 01:01:45，101，2，3，1，2（完成），银两200、经验400 2012-01-08 01:02:10，102，3，4，5，1（接受）， 2012-01-08 01:02:50，102，3，4，5，3（放弃）， ..... 这种数据log的的特点是带有有时间戳，是增量记录，之前的数据记录一般不会做修改。优点是保留了尽可能多的信息，可以在日后做更深入的分析与挖掘。但坏处是需要比较大的服务器资源开销，做数据分析前还需要做一定的数据预处理工作。
详细型的数据额外平添服务器的压力，于是在详细型数据的基础上，出现了累计型数据。例如银两产出，详细型数据的做法可能是： 玩家角色ID、等级、门派、时间戳、产出类型、产出数量 101，2，3，2012-01-09 00:00:00，1， 2 102，2，3，2012-01-09 01:00:15，2， 3 ...... 而累计型数据则是将一段时间内的每个玩家获得的产出银两数据进行汇总，例子如下： 时间戳、产出类型、产出数量 2012-01-09 00:00:00，1， 5000 2012-01-09 00:00:00，3， 4000 2012-01-09 01:00:00，1， 3000 2012-01-09 01:00:00，3， 5000 ......
累计型数据一般会抹掉玩家角色这个维度，对一定时间段内的数据进行汇总。这种做法的好处是数据存储空间小，几乎不需要做数据预处理的工作，就可以做数据分析；但坏处就是不能做太多深入的挖掘。例如哪些玩家获得最多的银两产出这些需求是不能满足的，因为没有记录玩家角色ID字段。
实际情况中，则需要根据综合数据需求与服务器资源两个方面考虑。例如银两产出，如果是从宏观角色监控经济系统的平衡，数据后台存储则可以采取累计型数据做法。但如果需要考虑玩家纬度，且服务器资源可以满足，则尽可能记录玩家角色等较多的字段。