3

我总共提出了三种不同的、同样可行的方法来保存图表数据。

有问题的图表是“随着时间的推移，玩家在各个类别中的得分”。类别包括“建筑”、“物品”、“任务完成”、“成就”等。

方法一：

CREATE TABLE `graphdata` (
    `userid` INT UNSIGNED NOT NULL,
    `date` DATE NOT NULL,
    `category` ENUM('buildings','items',...) NOT NULL,
    `score` FLOAT UNSIGNED NOT NULL,
    PRIMARY KEY (`userid`, `date`, `category`),
    INDEX `userid` (`userid`),
    INDEX `date` (`date`)
) ENGINE=InnoDB

此表包含每个用户/日期/类别组合的一行。要显示用户的数据，请选择userid。旧条目通过以下方式清除：

DELETE FROM `graphdata` WHERE `date` < DATE_ADD(NOW(),INTERVAL -1 WEEK)

方法二：

CREATE TABLE `graphdata` (
    `userid` INT UNSIGNED NOT NULL,
    `buildings-1day` FLOAT UNSIGNED NOT NULL,
    `buildings-2day` FLOAT UNSIGNED NOT NULL,
    ... (and so on for each category up to `-7day`
    PRIMARY KEY (`userid`)
)

由于是主键，因此按用户 ID 选择更快。每天的分数都会向下移动，如下所示：

... SET `buildings-3day`=`buildings-2day`, `buildings-2day`=`buildings-1day`...

条目不会被删除（除非用户删除他们的帐户）。可以使用INSERT...ON DUPLICATE KEY UPDATE查询添加/更新行。

方法三：

为每个用户使用一个文件，其中包含一个 JSON 编码的分数数据数组。由于无论如何都是通过 AJAX JSON 调用获取数据，这意味着可以静态获取文件（甚至缓存到下一个午夜），而不会对服务器造成任何压力。服务器每天运行每个文件，shift()从每个阵列中push()找出最旧的分数，最后将新的分数排在最后。

就我个人而言，我认为方法 3 是迄今为止最好的，但是我听说过使用文件而不是数据库的坏事——例如，如果我希望能够根据用户在不同类别中的分数对他们进行排名，那么这个解决方案将非常糟糕。

在这两种数据库解决方案中，我已经在我的一个较旧的项目中实施了方法 2，这似乎效果很好。方法 1 似乎“更好”，因为它更好地利用了关系数据库和所有这些东西，但我有点担心它会包含(number of users) * (number of categories) * 7行，这可能会变成一个很大的数字。

我有什么遗漏可以帮助我最终决定使用哪种方法吗？1、2、3或以上都不是？

4

2 回答 2

3

如果你要使用关系数据库，方法一比方法二好很多。它是规范化的，所以很容易维护和搜索。我会将该date字段更改为 atimestamp并调用它added_on（或者不是像“日期”这样的保留字）。我会添加一个 auto_increment 主键score_id，这样 user_id/date/category 就不必是唯一的。这样，如果用户设法在同一秒内将他的建筑分数增加两次，仍然会记录两者。

第二种方法要求您每天更新所有记录。第一种方法只进行插入，不进行更新，因此每条记录只写入一次。

... 设置buildings-3day= buildings-2day, buildings-2day= buildings-1day...

您真的想每天更新表中的每条记录，直到时间结束？！

由于是主键，按用户 ID 选择更快

由于user_id是方法 1 主键中的第一个字段，因此查找速度同样快。作为常规索引中的第一个字段（这是我上面建议的），它仍然会非常快。

关系数据库的想法是每一行代表一个实例/动作/发生。所以当用户做某事影响他的分数时，做一个 INSERT 记录他做了什么。您始终可以从这样的数据中创建摘要。但是您无法从摘要中获得此类数据。

其次，您似乎不寻常地担心摆脱旧数据。为什么？您的选择查询将具有自动排除旧数据的日期范围。如果您担心性能，您可以 根据行龄对表进行分区，或者设置一个 cronjob 以定期删除旧记录。

ETA：关于存储在文件中的 JSON

在我看来，这似乎将方法 2 的缺点（难以搜索，每个文件必须每天更新）与文件访问的其他缺点结合起来。文件访问是昂贵的。文件写入更是如此。如果您真的想存储汇总数据，我会仅在请求数据时运行查询，并将结果按 user_id 存储在汇总表中。该表可以保存一个 JSON 字符串：

CREATE TABLE score_summaries(
user_id INT unsigned NOT NULL PRIMARY KEY,
gen_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
json_data TEXT NOT NULL DEFAULT '{}'
);

例如：

Bob (user_id=7) 首次登录游戏。他在显示他每周统计数据的个人资料页面上。这些查询运行：

SELECT json_data FROM score_summaries 
  WHERE user_id=7 
    AND gen_date > DATE_SUB(CURDATE() INTERVAL 1 DAY); 
//returns nothing so generate summary record

SELECT DATE(added_on), category, SUM(score) 
  FROM scores WHERE user_id=7 AND added_on < CURDATE() AND > DATE_SUB(CURDATE(), INTERVAL 1 WEEK)
  GROUP BY DATE(added_on), category; //never include today's data, encode as json with php

INSERT INTO score_summaries(user_id, json_data)
  VALUES(7, '$json') //from PHP, in this case $json == NULL
  ON DUPLICATE KEY UPDATE json_data=VALUES(json_data)

//use $json for presentation too

今天的分数是根据需要生成的，而不是存储在摘要中。如果 Bob 今天再次查看他的分数，历史分数可以来自汇总表，也可以存储在第一次请求之后的会话中。如果 Bob 一周没有访问，则不需要生成摘要。

于 2012-05-28T20:12:38.113 回答
1

方法 1 对我来说似乎是一个明显的赢家。如果您担心单个表（graphData）的大小太大，您可以通过创建来减小它

CREATE TABLE `graphdata` (
    `graphDataId` INT UNSIGNED NOT NULL,
    `categoryId` INT NOT NULL,
    `score` FLOAT UNSIGNED NOT NULL,
    PRIMARY KEY (`GraphDataId'),
) ENGINE=InnoDB

而不是创建 2 个表，因为您显然需要将 graphDataId 与 userId 连接起来的信息

create table 'graphDataUser'(
         `graphDataId` INT UNSIGNED NOT NULL,
        `userId` INT NOT NULL,
)ENGINE=InnoDB

和 graphDataId 日期连接

create table 'graphDataDate'(
         `graphDataId` INT UNSIGNED NOT NULL,
        'graphDataDate' DATE NOT NULL
)ENGINE=InnoDB

我认为你真的不需要担心某些表包含的行数，因为大多数 dba 在行数方面做得很好。您的工作只是将数据格式化为易于检索的方式，无论检索数据的任务是什么。我认为从长远来看，使用该建议应该会有所回报。

于 2012-05-28T20:15:15.777 回答