1

我正在做一个在线游戏的爱好项目。该游戏将玩家数据存储在一个大的平面文件中。数据本身包含玩家的所有信息,从名称到玩家本身的物品。它本身就是相当多的列,并且有几十个项目只会增加启动的平面文件大小。

给你一个视觉。我当前的播放器文件是 192 列(不考虑项目)。

球员资料

减少绒毛后,我的平面文件中有 51 列用于播放玩家数据。这不包括玩家的物品或能力。我已经决定可以将它们分成单独的表并与 FK 链接。

51 列数据对玩家来说是唯一的,不应重复。它们不是我被告知的正常化的良好候选者。

桌子

  • ID
  • 姓名
  • 密码
  • 种族
  • 性别
  • 班级
  • 等级
  • 金子
  • 经验
  • 寻求
  • 盔甲
  • 力量
  • 智慧
  • 灵巧
  • ETC

活动

但是,选择和更新这些列中的一些列时的活动彼此之间有很大的不同。有些在玩家移动时更新,有些在玩家登录游戏并加载到内存时很少使用。记录永远不会被删除或重建。每列都有一个值。活动频率从每秒到每月一次不等。

问题

这就引出了一个问题。如果它们在同一个表中,我是否可以根据活动将这些列拆分并提高性能,而不是传统的数据规范化方式?或者我应该把它们放在同一张表上,只依靠正确的索引?大多数列看起来不错,但就像我说的,有些列比其他列使用得更多。但是,当一些人比其他人更多地使用时,会有很大的不同。这种感觉让我很害怕。

4

1 回答 1

1

您提到的称为非规范化,实际上是一个众所周知且经常发生的事情。

没有关于何时进行非规范化的一般规则和指示。这取决于每个项目特有的许多事情(例如硬件、数据库的类型以及您提到的“活动”等等),因此归结为对每个应用程序进行分析以得出结论。

此外,有时非规范化意味着将一个表拆分为具有一对一关系的两个表(就像您的情况一样)。有时这意味着摆脱 FK 并将所有内容放在一个包含许多列的 BIG 表中,以避免在选择时进行连接。

最重要的是,请记住,您的问题更多的是关于性能而不是关于可伸缩性。分成不同的表/数据库意味着您最终可以将数据存储在不同的机器中,每台机器都有特定的硬件架构和适合用例的数据库。


游戏行业的非规范化示例

对于 MMORPG,我能想到的一个非规范化示例是将所有不经常更改的用户数据存储在 BLOB 中。这不仅是非规范化的,而且整行都存储为一系列字节。EF Codd 博士一点也不高兴。

Playfish是一家这样做的公司。

这意味着您可以以较慢的更新为代价获得更快的选择,最重要的是,为用户更改架构变得非常麻烦(但这里的原因是它始终是, ,直到时间结束)。这也意味着您的用户数据现在可以存储在更简单的键/值存储中,而不是具有更多开销的 RDBMS。当然,获取用户信息的登录服务器不需要像处理游戏玩法的那样高效。UsernamePasswordE-mail


因此,请尝试阅读有关非规范化的用例(这是一个非常活跃的主题),看看您可以在哪里应用您的发现。另外,请记住,预优化有时会适得其反,也许您现在应该专注于开发您的游戏。当您遇到扩展/性能问题时,您很可能会获得大量用户所带来的资金来解决问题。祝你好运!

于 2013-08-25T19:02:05.953 回答