大行其道的今天，本周，本月 - 设计模式 [英] Popular Today, This Week, This Month - Design Pattern

问题描述

我有一个显示订购三种领域，最流行的今天，本周和本月项的系统。每次一个条目观察的评分是通过1从而改变顺序递增。

I have a system that displays entries ordered by one of three fields, the most popular Today, This Week and This Month. Each time an entry is viewed the score is incremented by 1 thus changing the order.

因此​​，如果第1项是新的，今天看到10倍的成绩将是：

So if entry 1 is new and viewed 10 times today its scores will be:

Today: 10
Week: 10
Month: 10

目前的解决方案

目前，我只是有3个与每一项目相关的领域，一个是今天另一个本周，另一个是这个月。每次一个条目被观看所有三个分数递增1

At the moment I simply have 3 fields associated with each entry, one for today another for this week and another for this month. Each time an entry is viewed all three scores are incremented by 1.

在一天结束时，天得分被重置为0。在当前周的周得分被设置为0和在当前压延月份结束的端部，该月的分数被设定为0。

At the end of the day, the day score is reset to 0. At the end of the current week the week score is set to 0 and at the end of the current calender month, the month score is set to 0.

问题

虽然此工作，并使用小的空间是不理想的，原因有两个：

Although this works and uses little space it is not ideal for two reasons:

1）在当前时间（天，周，月）的最后的值被重置为0，一下子这意味着每天在00:00:00的排名是所有复位，所有日常的分数都设置为0时，同样是如此的周端和月末。 00:00:00在每个月的1日所有得分都设置为0失去所有现有的排名数据。

1) At the end of the current period (day,week,month) that value is reset to 0 all at once meaning that at 00:00:00 every day the ranking is all reset and all daily scores are set to 0, the same is true for end of the week and end of the month. At 00:00:00 on the 1st of each month all scores are set to 0 loosing all existing ranking data.

2）由于月底一般落在一周（周一至周日）内，每月得分在一周内导致每周分数比每月得分越高复位。

2) Because the end of the month usually falls inside a week (Mon-Sun), the monthly scores are reset during the week leading to weekly scores being higher than monthly scores.

可能的解决方法

我可以使用轧制每小时计数器每小时本月被用于计算分数基于当前小时索引的当前天，周，月

I could use a rolling hourly counter for every hour of the month which is used to calculate the scores for the current day,week,month based on the current hour index.

Array size = 31 * 24 = 744 int16 values

所以一日在凌晨4点视图将被放置在小时[4]

So on the 1st at 4am a view would be placed in hours[4]

hours[4]++

的统计计算器随后将然后使用今天作为最后24值的总和与本周得分将是最后（24 * 7）值的总和。最后，这个月将是最后的（24 * 31）值的总和。

The stats calculator would then then use today as the sum of the last 24 values and the This Week score would be the sum of the last (24*7) values. Finally the This Month would be the sum of the last (24*31) values.

解决的问题

与解决方案1中的主要问题是磁盘/内存需求。我已经从我目前的解决方案使用3个32位的值，使用744 32位值。即使我将其更改为IN16我仍然将使用每个条目更大量的内存

The major issue with solution 1 is the disk/memory requirements. I've gone from using 3 32 bit values in my current solution to using 744 32 bit values. Even if I change them to in16 I'm still going to be using a lot more memory per entry

Memory per Entry = 3 * 4 bytes = 12 bytes (Existing)
Memory per Entry = 744 * 2 = 1,488 bytes (possible solution)

通过这种解决方案我的每个条目的内存使用情况已上升12400％！

With this solution my memory usage per entry has jumped 12400%!!

任何人都可以提出能够满足解决问题，我目前的解决方案，但没有使用每个条目1.5k的另一种解决方案？

Can anyone suggest another solution that would meet resolve the issues in my current solution but without using 1.5k per entry?

非常感谢！

推荐答案

这其实是一个普遍的问题组如何将数据既能够有效并保留所有必要的信息。

This is actually a common problem of how to group data both effectively and keep all the necessary information.

首先：你有没有尝试做它自己的方式？难道你真的缺少存储？您的解决方案似乎是合理的。

First of all: Did you try doing it your way? Did you really lack the storage? Your solution seems reasonable.

我假设你正在使用一个数据库保存数据。

I assume that you are using a database for keeping the data.

我会创建两个单独的表，一个是每小时，一个是每日的统计数据。每篇文章将在该数据库为每个小时，正好是24行。这将用于每小时统计。要更新特定行，你只需要知道的小时（0-23）和entry_id。 更新计数=计数+ 1，其中小时= 11和entry_id = 18164;

I would create two separate tables, one for hourly and one for daily statistics. Each article would have exactly 24 rows in that database, one for each hour. That would be used for hourly stats. To update a specific row you would only have to know the hour(0-23) and the entry_id. UPDATE count=count+1 WHERE hour=11 AND entry_id = 18164;

entry_id foreign key | hour integer | count integer
---------------------+--------------+--------------
1                    | 0            | 123
1                    | 2            | 1712
...

目前每天的统计是，要么在午夜计算（或当应用程序做最少的），或者概括的需求。无论哪种方式，每天一次，一总和将必须进行所有的每小时数据的和的总和将必须被插入每日统计表

entry_id foreign key | day date   | count integer
---------------------+------------+--------------
1                    | 2013-07-03 | 54197
1                    | 2013-07-04 | 66123
...

每个条目超过31（30/29/28）天应该被删除。还是不行，如果你想全部或每年的数据统计

Each entry older than 31 (30/29/28) days should get deleted. Or not, if you want total or yearly statistics

优点

• 您保持高于全每小时统计数据较少：24 + 31
• 在款项每小时的表应该是快，如果索引的entry_id和一小时
• 少使用比你的解决方案的内存

缺点

• 在附加的脚本/触发器/需要每天更新统计工作
• 需要更多的工作比在您的解决方案

这篇关于大行其道的今天，本周，本月 - 设计模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！