在游戏开发设计中,玩家作为一个游戏对象,他们之间可能会存在多种关系,比如:
- 好友关系;
- 组队关系;
- 公会关系;
- 买卖关系;
- ……
无论是使用关系型数据库还是key/value型的NoSQL ,按照传统思路对于这些关系的存储结构实现大同小异。例如:玩家会有独立的好友关系数据块,数据块内部至少存储着好友唯一ID,可以通过好友ID索引到好友相关信息;公会存在唯一ID,通过这个ID拉取公会成员信息和其他信息;组队与公会类似…
传统数据库与图数据库思路比对
我们列举一下好友与公会的常规操作,在不考虑合法性校验的情况下:
操作 | 传统方式 | 图数据库方式 |
玩家A和B成为好友 | 玩家A和B分别在好友数据块增加对方ID | 两对象A和B之间增加边 |
玩家A和B解除好友 | 玩家A和B分别在好友数据块删除对方ID | 两对象A和B之间删除边 |
玩家A加入公会C | 玩家A记录所属公会ID,公会C在成员列表加入玩家A | 两对象A和C之间增加边 |
玩家A离开公会C | 玩家A删除所属公会ID,公会C在成员列表删除玩家A | 两对象A和C之间删除边 |
直观感觉上使用图数据库方式更简洁一些,传统方式若做得严谨一些可能还需要考虑事务的支持,根据数据库的选型不同会导致数据一先一后写入,需处理先写入成功后写入失败的场景。
为了凸显差异性,这次我们再假设一些更复杂的操作,比如在推荐系统中常见的场景,同样也是不考虑合法性校验的情况下:
Read More →