Счётчик кликов: IP+SQL, cookies, или другой вариант?

amdbodia, 534 просмотра

Есть необходимость считать клики по кнопке в блоге. Кнопка есть в каждой статье и обычно кликают около 100 пользователей.
Необходимо, чтоб в каждой статье клик каждого пользователя считался только один раз.
Варианты реализации (пока вижу только 2 приемлемых):
1. Заносить IP в БД.
Плюсы: мускул уже установлен, скрипт и так работает с ним.
Минусы: 100 статей * 100 кликов = 10^4 записей в БД. Создавать отдельную таблицу для каждой статьи - не вариант, а выполнять поиск в одной таблице с десятью тысячами записей и по IP и по ID статьи - не долго ли? Да и сколько будет весить такая таблица?
2. Устанавливать cookies в браузер пользователя.
Плюсы: не насилуем свой мускул.
Минусы: меняем браузер/удаляем cookies - мелкопакостим кликами сколько угодно.

Что из двух зол выбрать?
Если SQL, то может есть вариант сохранения к примеру всех IP к одной статье в одном текстовом поле, а потом функциями php нахождения этих IP из текстового поля? И как быть с IPv6? Вообще, это очень будет нагружать BD?

Если cookies - то, например, если пользователь пожелает кликать в каждой статье, это ему 100 записей передать?

Может есть другие варианты, а я пока не в курсе? :-)

Ответы:

Есть еще стопроцентный вариант, ставить быстро устаревающую куку при посещении страниц сайта и отдачу картинок производить при ее наличии

Стопроцентно верная голосовалка может быть только для зарегистрированных пользователей, да и то виртуалов могут наплодить. Занесение IP в базу данных плохо тем, что сегодня IP в подавляющем большинстве случаев никак с пользователями не связаны. В одних случаях могут заходить сотни _разных_ пользователей с одного IP, потому что провайдер их через NAT пускает, в другом случае диалапный пользователь может перезвонить и получить новый IP из диал-апного пула, и тут же проголосовать еще. Так что если голосование для всех, идентифицируемое по IP, то цифры примерные и можно считать их верными, только если объем проголосовавших достаточно большой и по закону больших чисел влияние технических моментов типа NAT оказывается для всех вариантов примерно одинаковым.
А десять тысяч записей для БД - это жалкие копейки, можешь даже не думать о быстродействии в данном случае - конечно, если не забыл индексы по нужным полям проставить. IP хранить лучше всего в бинарном виде (UNSIGNED INT), конвертируя их из текста функцией INET_ATOI(). Или в текстовом виде, если скрипт будет учитывать всякие x-forwarded-for и клеить все найденные прокси в общую цепочку. Об IPv6 можешь не думать - пока его применение очень ограничено. Конечно, когда он _реально_ войдет в нашу жизнь, все станет гораздо проще - хотя бы потому что каждый пользователь сможет получить уникальный постоянный IP.

Японский Городовой

И не надо бояться размера базы.
Очень смешно выглядят рассуждения о "насилии".

15 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.