Лучший способ хранить "просмотры" темы - PullRequest
1 голос
/ 25 июня 2009

Я использую этот код для обновления просмотров темы.

UPDATE topics 
SET views = views + 1 
WHERE id = $id

Проблема в том, что пользователям нравится спам на F5, чтобы получить смешное количество просмотров.

Как мне поступить, чтобы получить уникальные хиты? Сделать новую таблицу, где я храню IP? Не хочу хранить его в куки. Слишком легко очистить ваши куки.

Ответы [ 5 ]

2 голосов
/ 25 июня 2009

Я бы создал отдельную таблицу для хранения этой информации. Затем вы можете захватить больший объем данных и не требовать обновления таблицы, которая может быть прочитана чаще всего.

Вы всегда будете использовать INSERT INTO tblTopicViews ...

И вы захотите собрать как можно больше информации, IP-адреса, даты и времени попадания, возможно, некоторую информацию о версии браузера, операционной системе и т. Д. - все, что вы можете получить. Таким образом, вы сможете настроить фильтрацию запросов на обновление по времени.

Стоит помнить, что многие пользователи могут использовать один и тот же IP-адрес - например, весь офис может работать через один и тот же маршрутизатор.

1 голос
/ 25 июня 2009

Я бы создал таблицу, в которой хранятся уникальные представления:

CREATE TABLE unique_views(
    page_id number,
    user_agent varchar2(500),
    ip_address varchar2(16),
    access_time date,
    PRIMARY KEY (page_id, user_agent, ip_address, access_time)
)

Теперь, если кто-то заходит на страницу и вы хотите разрешить один просмотр на пользователя в день, вы можете сделать

INSERT INTO unique_views (:page_id, :user_agent, :ip_address, trunc(SYSDATE, 'day'))

, что не позволит дублировать просмотры для одного и того же пользователя в течение одного дня. Затем вы можете подсчитать количество просмотров для каждой страницы с помощью простого GROUP BY (пример для сегодняшних просмотров):

SELECT page_id, count(*) page_views
FROM unique_views
WHERE access_time = trunc(SYSDATE, 'day')
GROUP BY page_id
0 голосов
/ 25 июня 2009

Обратите внимание, что из-за различных проблем (например, неизвестного поведения серверов кэширования) подобные вещи всегда будут неточными и балансом между различными факторами. Тем не менее, для грубого неопределенно надежного счетчика использование отдельной таблицы, как предлагают Карл Бартель и другие, является достойным решением.

Однако, в зависимости от того, насколько серьезно вы относитесь к этой проблеме, вы можете не указывать «user_agent» - это очень легко подделать, поэтому, если я действительно хочу накачать счетчик посещений, я могу набрать хиты с помощью скрипта это вызвало мою страницу с user-agent = "bot1", затем снова с того же IP с "bot2" и т. д.

Но тогда 2 пользователя за одним IP будут учитываться только как 1 попадание, поэтому вы теряете точность - понимаете, что я имею в виду относительно баланса между различными факторами?

0 голосов
/ 25 июня 2009

Вы можете использовать session_id () для различения разных пользователей, очевидно, вам нужна отдельная таблица для отслеживания каждого посещения.

ОБНОВЛЕНИЕ: Я только что заметил, что вы не хотите зависеть от куки, поэтому это может не подойти вам.

0 голосов
/ 25 июня 2009

Ну, вы можете записать отдельные обращения к страницам в журнальную таблицу, включая идентификационную информацию, такую ​​как готовка или IP-адрес. Вы можете проанализировать эту таблицу на досуге.

Но у веб-сервера, вероятно, есть средство для этого. Я знаю, что IIS и Apache могут создавать подробные журналы использования. И для обоих, есть множество инструментов для построения графиков и анализа, которые учитывают такие вещи, как IP-адреса.

Таким образом, вместо того, чтобы вести собственную регистрацию, вы можете использовать веб-сервер.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...