Как лучше всего организавать хранение "нравица"-"не нравица" для статей или постов в базе данных?

Например, голосовать может за один пост один ip адрес, база — мускул, таблицы innoDB.


Нужно организовать хранение голосов в базе с наименьшими затратами ресурсов и с максимальной скоростью подсчета рейтинга для статьи.


Я думаю структура таблицы следующая:


article_id (int 11)

ip (varchar 15)

mark (enum ("-1",«1»))


PrimaryKey по двум первым полям. Скорее всего, можно сделать проще, поделитесь опытом, пожалуйста.
  • Вопрос задан
  • 2912 просмотров
Пригласить эксперта
Ответы на вопрос 3
Dunadan
@Dunadan
Ну если нужно только считать, то вполне достаточно просто добавить поле rating в таблицу со статьей и увеличивать / уменьшать ее значение программным образом.

Таблица нужна только тогда, когда требуется накладывать ограничения по времени, ай-пи адресу и пр. Хорошим тоном считается не хранить ай-пи адрес в виде строки, а записывать его числовое значение (если пишете на php — php.net/manual/en/function.ip2long.php).

Причем при выводе ленты новостей весьма полезно аггрегированное значение рейтинга таки хранить в отдельном поле в таблице статей — что бы не пересчитывать его каждый раз. Обновлять его можно триггером на стороне СУБД или программно.
Ответ написан
по ip не очень хорошо т.к. некоторые провайдеры на кучу пользователей сразу вешают 1 ip, а у пользвателей мобильного интернета так вообще часто 1 ip на всех

Имхо дучше ставить куку с каким-нибудь уникальным токеном и по ней смотреть, чем по ip
Ответ написан
deemytch
@deemytch
linux root, ruby/perl programmer, sql, backend.
Дополнение к предыдущему оратору — печальный опыт — от накрутки избавиться нельзя. Можно только минимизировать её совокупностью административных и технических методов.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы