适当的独特新闻文章视图计数器方法

时间:2011-07-13 20:46:42

标签: php views

我已经研究了不同的方法来解决这个问题,但我想要一种不允许人们绕过它的方法。只需要一个简单,轻量级的方法来计算存储在数据库中的不同新闻文章的观看次数:

    id    |    title    |    body    |    date    |    views    
     1      Stack         Overflow     2010-01-01   23
  1. 会话      - 他们不仅可以清除浏览器数据并重新加载另一个视图的页面吗?有办法阻止这个吗?
  2. ip地址的数据库表      - 大量的条目,可能会妨碍表现
  3. 日志文件      - 与数据库相同但我见过很多例子
  4. 对于性能关键系统和确保准确性,我应该进一步研究哪种方法?

    感谢。

3 个答案:

答案 0 :(得分:2)

如果您想知道您对给定页面有多少唯一身份访问者,那么您需要在应用程序的某个位置保留每个访问者唯一的信息以供参考。

IP地址绝对是“最安全”的方式,因为用户必须通过很多环节来手动更改其IP地址。话虽如此,如果这是每个页面的商业网站,你将不得不存储大量的数据。

更合理的做法是将信息存储在客户机器上的cookie中。当然,如果您的客户不允许使用cookie,您将有一个偏斜的数字,并确保用户可以擦除他们的浏览器历史记录,并且您的数字会有偏差,但总体而言您的数字应该相对准确。

您可能会保留此信息的缓存或会话级变量,但如果您的应用程序崩溃或重新启动,那么您就是SOL。

如果你真的需要几乎100%准确的数字,那么你最好的办法就是记录每个页面唯一访问者的IP地址。这将确保您获得最准确的计数。这是非常极端的,如果你能在准确度上达到~5 +%的命中率,那么我肯定会去找饼干。

答案 1 :(得分:1)

我认为为了保持轻量级,您应该使用其他人的处理能力,因此您应该注册Google Analytics并将其代码插入您要跟踪的网页中。

如果您想要更高的准确性,那么跟踪数据库本身的每个数据库请求;或者使用日志读取工具,然后每天将页面读取摘要丢弃到数据库或文件系统中。

答案 2 :(得分:0)

另一个建议:

当用户访问您的网站时,请在表格中记录他们的IP地址并删除具有唯一ID的Cookie。将此唯一ID存储在表中,并提供对IP地址记录的引用。通过这种方式,您可以计算出更准确的计数(并对您的最终数字进行调整)

设置自动化任务以创建汇总表 - 更快地查询数据。这也将允许您定期修剪数据。

如果您愿意牺牲更高的准确度,那么这可能是一个解决方案:

这将是“持有”表 - 其中包含原始数据。这不是您用来查询数据的表 - 它只是用于写入。您每天/每周/每月都会浏览整个表格。再一次 - 您可能需要索引取决于您希望如何修剪它。

CREATE TABLE `article_views` (
  `article_id` int(10) unsigned NOT NULL,
  `doy` smallint(5) unsigned NOT NULL,
  `ip_address` int(10) unsigned NOT NULL
) ENGINE=InnoDB

然后你会有一个汇总表,你可以每天/每周或每月更新一次,这将非常快速地查询。

CREATE TABLE `summary_article_uniques_2011` (
  `article_id` int(10) unsigned NOT NULL,
  `doy` smallint(5) unsigned NOT NULL,
  `unique_count` int(10) unsigned NOT NULL,
  PRIMARY KEY (`article_id`,`doy`),
  KEY(`doy`)
) ENGINE=InnoDB 

示例查询:

一天中特定文章的唯一计数:

SELECT unique_count FROM summary_article_uniques_2011 WHERE article_id=? AND doy=" . date('z') . "

特定文章每天的计数:

SELECT unique_count FROM summary_article_uniques_2011 WHERE article_id=?

计算整个网站,今天最受欢迎的文章:

SELECT article_id FROM summary_article_uniques WHERE doy=? ORDER BY unique_count DESC LIMIT 10 // note this query will not hit an index, if you are going to have a lot of articles your best bet is to add another summary table/index "unique_count"