方法1：

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)

方法2：

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查询添加/更新行。

方法3：

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

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

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

我有什么遗漏可以帮助我做出最终决定使用哪种方法？上面没有1,2,3或者没有？

Answer 1

如果您要使用关系数据库，方法1比方法2好得多。它已经标准化，因此很容易维护和搜索。我将date字段更改为timestamp并将其称为added_on（或者不是像'date'这样的保留字的内容）。我会添加一个auto_increment主键score_id，以便user_id / date / category不必是唯一的。这样，如果用户设法在同一秒内两次增加他的建筑分数，则两者仍将被记录。

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

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

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

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

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

关系数据库的想法是每行代表一个实例/动作/事件。因此，当用户做某事影响他的分数时，请执行INSERT记录他所做的事情。您始终可以根据此类数据创建摘要。但是你无法从摘要中获得这种数据。

其次，你似乎不情愿地担心摆脱旧数据。为什么？您的选择查询将在其上具有自动排除旧数据的日期范围。如果您关注性能，可以根据行年龄partition表格或设置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没有访问一周，则不需要生成摘要。

Answer 2

方法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在行数方面做得很好。无论检索数据的任务是什么，您的工作只是以简单的方式获取数据格式。使用这个建议，我认为应该从长远来看是有回报的。

存储图表数据的最有效方法

方法1：

方法2：

方法3：

2 个答案:

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