В каком виде хранить данные о посещаемости товаров?

Question

[Max Ba]

Парни, вопрос. Нужно на сайте отображать количество просмотров товаров желательно с блокировкой от накручиваний. Как на авито (сколько всего просмотров)

Таблица MYSQL

CREATE TABLE `statictica` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `date` timestamp NOT NULL default CURRENT_TIMESTAMP,
  `ip` char(32) NOT NULL,
  `product_id` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `ip` (`ip`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Моя схема такова
1) Проверяем хэш данные связки пользователя md5( IP ) - product_id
2) Если нет таких значений за последний час то записываем
3) Если есть, то игнорируем.

Вопрос с куками я не поднимал, тк меня интересует именно интервал "за последний час" был ли пользователь в данном товаре или нет. А вопрос больше в том, справится ли сервер с постоянно проверкой записей в таблице статистики, если например сильно возрастет нагрузка.

Выходит, мне надо задействовать две таблицы. 1 (выше) с данными посещаемости 2. Делать UPDATE `stat` = `stat` + 1 в основной таблице товаров.

Может все гораздо проще?

Comments

[newpy]

Если абстрагироваться: берем юзера, проверяем дату просмотра товара, если дата больше часа, то инкремент и UPDATE, если нет, оставляем как есть. Все как ты описал. Разве что `stat` лучше хранить в первой таблице (statistics) вместе с датой, а не в товарах. И получать ее через релейшн нечто вроде
$product->statistics->stat

[Max Ba]

У меня на 1 товар всегда приходится сколько то просмотров. От 0 и выше. Поэтому данное поле лучше оставить в таблице товаров. В принципе, я и кроном могу его обновлять. Другое дело, основная таблица именно статистики. Вот по не и непонятно. Тоесть мне проверять дату через now() - interval 1 hour так? Может как то можно, что запрос кэшировался, а не пересчитывался каждый заход?

Answer 1

[Алексей Сундуков]

Пишите сразу md5 хэш в базу. По нему ставим индекс который и используем при поиске. Справиться ли сервер зависит от посещаемости, характеристик самого сервера, количестве данных в базе. Заполните базу фейковыми данными и посмотрите, сразу станет понятно.

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

Comments

[Max Ba]

Ну мне надо где-то хранить просмотры по ip! Если например в первой таблице важна только 1 цифра это сколько всего пррсмотрели, то вторая таблица (статистики и ip) как раз и нужна для "сырых" данных, черновой работы. Я в комменте выше, задал вопрос, про проверку даты. Правильно это или нет? И касаемо ключа, лучше использовать char32 и в php его делать на основании md5(id+product_id) ? Вы это имели ввиду?

[Max Ba]

* ip+product_id

[Алексей Сундуков]

maximka787: Так такая в итоге цель-то? Хранить просмотры или не давать накручивать счетчик? И главное, что есть просмотр? Исходя из описания это ip+product_id один раз в течении часа. Но и тут много тонкостей. К примеру, через час и одну минуту снова просмотр товара Х с адреса Y. А еще через час опять смотрят товар Х с адреса Y. Сколько просмотров? Один? Три? В общем перед проектирование схемы базы данных нужно для начала записать алгоритм подсчета. Лучше в виде блок-схемы.
Касательно ключа да, именно это.

[Max Ba]

Спасибо за Ваши советы. На счет ключа остановился на этом варианте, для моих целей вполне приемлем $id = md5($_SERVER['REMOTE_ADDR'].date('Y-m-d H').$id_product);
Ну а по логике, пусть накручивают понемногу, мне главное, чтобы такие методы, как залипание F5 (образно) или тот же DOS не вывел из строя систему.

[Алексей Сундуков]

maximka787: От атаки такие методы не спасают. Совершенно. Атака это вообще из другой области и методы решения там совершенно другие. И обычно они не связаны с кодовой базой сайта. А статистика все равно будет искаженной. Потому что под одним IP может быть очень много реальных пользователей. У нас в одном из проектов примерно 2 тыс. пользователей сидящих на одном IP адресе (судя по всему какая-то подмосковная локальная сеть из тех, которые еще не сожрали большие операторы). А точно известно, что это реальные люди, потому что у них есть заказы и точные адреса доставок. С вашей схемой это будет один просмотр, хотя реально их может быть сильно больше.