mysql - SQL中玩家得分表的结构

Question

我需要将游戏得分表从(请不要笑...)*.ini 数据库 迁移到 SQL 表，因为我想将整个游戏迁移到 MySQL 库。

需要将用户分数存储在数据库中，以便能够检索总体/年/月/周/日时间跨度的结果表。每年需要:{year score} + {month score}*12 + {week score}*52 + {day score}*360 = ~425 rows per user + 1 {overall score} row per user。这感觉并不优化，这就是我提出这个问题的原因。

使用什么基础？上面提到的，是时间跨度的基础，使用这样的结构:

{timespan type} {timespan} {user ID} {score for type 1} {score for type 1} {score for type 1} {score for type 2}

我需要注意的另一件事。不同的分数类型有不同的方法来排序。如果第一种类型是普通分数，我取最高(更多 - 更好)，那么第二种类型是速度，我按最快速度排序(更小 - 更好)。

如果您有疑问:“为什么要将周/月/年/整体的行分开？”，那么答案是，我想要一些快速的方法来获取结果表，例如，首先是上周得分类型 2 3 个地方。

我在想，也许，如果我只存储 {day score}，那么在当前结构中摆脱每个用户 426-360=66 行，从而产生新的结构:

{user ID} {day number} {score for type 1} {score for type 1} {score for type 1} {score for type 2}

我将如何获得“前 3 名最佳速度得分，上周”。这将需要一些多层次的计算......

1. 查询包含天数的行，这些行进入所有用户前几周的时间范围
2. 将每个 {user ID} 的所有分数相加或获得最低分数(取决于分数类型)并放入新表中
3. 查询新表，按分数列 ASC 或 DESC 排序(取决于分数类型)并检索前 3 行
4. 对每个分数列重复第 2 步和第 3 步

如果我想每分钟执行 1-3 次以上(因为在表中每次输入新内容后，我需要评估特定用户获得多少积分才能获得更高的排名，我想，这需要一些严重的服务器资源。根据问题顶部给出的结构(时间跨度基础)，每个分数列只需要第 3 步。

感谢您的回答和建议!

当前数据格式如下:

Overall file: overall.ini
(in folder of yearnumber) Year file: 2011.ini
(in folder of yearnumber) Month files: m1.ini ... m12.ini
(in folder of yearnumber) Week files: n1.ini ... n52.ini
(in folder of yearnumber) Day files: m1d1.ini ... m12d1.ini

内部存储的数据:

[~REZ~]
User13245325=1145 203.433 3 1.735
User3425435=1412 173.871 8 2
User32487854=18 76.253 1 11.016
User345645=2153 155.139 8 2.344
User65875=100 67.767 2 10.016
User453325=26 138.568 1 3.031

PS:这是一般性问题，与游戏开发没有直接关系，所以请不要把它扔到游戏开发 SO 部分。

Answer 1

老实说，我真的很难理解你在这里问的问题 - 但如果我理解正确的话，还有其他一些系统记录了实际的游戏结果，你想把这些游戏数据变成排行榜样式的数据结构，并且您希望查询运行得非常非常快。

所以，首先 - 您似乎担心数据的大小。除非您处理的是绝对天文规模的数据(Google、Facebook、Twitter)，否则您可能不需要这样做。磁盘空间很便宜，索引良好的数据库处理数百万行和处理数十行一样快。

从广义上讲，您需要决定是否要以空间(预先计算结果)换取速度，以及何时进行计算。

一般来说，使用“原始”数据并在运行时计算结果是最容易理解和维护的，并且出现错误的风险最低 - 但也可能是最慢的。尽管如此，这就是我要开始的地方。你没有说明你的“原始”数据是如何存储的，或者它更新的频率，但我会首先编写一个查询来生成你想要的数据。如果这很棘手，我会将一些中间步骤考虑到 View 中以简化查询。

然后，我会使用负载测试工具(JMeter 或类似工具是完美的)来衡量性能。

如果 - 但仅当 - 它真的太慢了​​，我会开始逐渐将 View 转换为预先计算的表，通过引入常规批处理作业来填充这些 View 。这完全取决于您的数据以及允许的“陈旧”程度。

您通常可以通过这种方法获得非常好的性能提升 - 只要批处理作业运行...，该解决方案仍然相当简单且不易出错......

只有当该方法遇到性能瓶颈时，我才会考虑对整个数据集进行预计算。在这种情况下，您不妨创建一个与您要输出到屏幕的表格完全相同的表格。