本文共 707 字，大约阅读时间需要 2 分钟。

游戏系统的数据可以分为两大类。一类是由策划童鞋配置的玩法规则，称为策划数据或配置数据；一类是保存玩家或公共信息的数据，称为用户数据。一般说来，策划数据只能由程序读取而不能修改，而用户数据则增删查改都会涉及。

对待玩家数据的严谨态度，无论怎么重视都不为过。玩家数据，正如游戏系统的血液。只有保证玩家的数据安全，才能留得住玩家的玻璃心。如果玩家今天历尽艰难险阻，耗尽所有rp刷到一件极品装备，明天上线发现装备不见了，肯定会跑到客服大吵大闹。

游戏服务端一般采用的数据库是关系型数据库，用mysql就足够了。当然，也有少数游戏公司采用MongoDb。

本文将从数据持久层框架的选择、数据表结构的设计以及数据入库模型三个方面，讨论相关解决方案。

• 关于数据的持久层方案

以前做web的时候，持久层一般都采用诸如mybatics或hibernate等ORM框架。游戏后端需要保存玩家及公共数据，持久层框架也可以采用mybatics等。

总体来看，游戏项目对数据库操作的要求比较低。一般都是对单表进行增删查改，很少有联表的操作。因此，很多公司都会有自己沉淀的一套持久层框架。例如有公司利用JDBC的ResultSetMetaData元数据获取列信息，然后与实体bean的field进行映射，将数据表的每一列跟对应的bean属性对应起来。当数据需要入库的时候，就调用bean对应的所有getter方法拼装成insert或update语句；读取数据则调用bean对应的所有setter方法，将数据表记录注入到实体里。这种方法是我见到的最有意思的持久化方案。也有一些小项目甚至直接使用jdbc进行数据库操作。

• 关于玩家数据表的设计方案