SQL中球员得分表的结构答案

【问题标题】：Structure of player score table in SQLSQL中球员得分表的结构
【发布时间】：2011-08-02 21:36:27
【问题描述】：

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

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

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

{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 名”。这需要一些多层次的计算......

查询所有用户前几周的时间跨度内包含天数的行
对每个 {user ID} 的所有分数求和或获得最低分数（取决于分数类型）并放入新表中
查询新表，按分数列 ASC 或 DESC 排序（取决于分数类型）并检索前 3 行
对每个分数列重复步骤 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部分。

【问题讨论】：

您能否发布一些您当前存储在 inifile 中的数据。它可能会澄清一些事情。事实上，我发现你的问题很难理解。看看你明确付出的努力和缺乏答案，其他人也是如此。
@Lieven 检查编辑，我已包含当前数据格式。

标签： mysql sql datatable

【解决方案1】：

我建议两张桌子。

用户，带有相关的用户信息，以及带有分数信息的分数。

分数看起来像：

score
------
user_id
speed
score_total

您的所有聚合都可以通过查询轻松完成。

【讨论】：

【解决方案2】：

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

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

一般而言，您需要决定是否要以空间（预先计算结果）换取速度，以及何时进行计算。

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

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

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

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

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

【讨论】：

好的，如果我不再担心存储和执行速度。我应该从什么最基本的结构开始？基本上，这些分数的格式为“{date} {user Id} {score type1..type4}”。
+1 没有太多可在此处添加的内容。 AFAICT，一张表和三列就足够了：用户名、时间戳和分数。这样，您就可以生成所需的所有结果并使其易于维护。
@Lieven 你的意思是，像日志文件？ {timestamp} {user id} {score}?
@Deele，几乎是的。如果您发现这方面存在问题，请告诉我们您认为问题所在，这样我们就可以提出解决方案，而无需更改您的结构（或调整结构）。
@Lieven 如果我采用 log'file 方法，那将占用太多空间。分数的添加非常频繁（每分钟最多 5 次），每年最多会产生约 2 600 000 个条目。在阅读了你所有的答案后，我想，我会构建某种 {timestamp with year+month+date} {user Id} {scores} 并尝试进行查询，以获取结果表，根据我的需要，导致 {2011.04.11} {user 1} {123} 和 {2011.04.11} {user 2} {124} 和 {2011.04.10} {用户 1} {56}