在游戏开发设计中，玩家作为一个游戏对象，他们之间可能会存在多种关系，比如：
- 好友关系；
- 组队关系；
- 公会关系；
- 买卖关系；
- ……
无论是使用关系型数据库还是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 →