Схема таблиц, как организовать рейтинг с плюсами/минусами?

Question

[Kir Shatrov]

Необходимо сделать рейтинг постов/комментов, как на Хабре.

Имею в виду плюсы и минусы и то, что нельзя головать больше одного раза.


Как организовать схему таблиц в MySQL? Сейчас рейтинг хранится в поле rating у самой записи, но так посетитель может голосовать больше одного раза.

Answer 1

[Doktor_Gradus]

Промежуточная таблица posts_users_rel со структурой: id int, post_id int, user_id int

При голосовании посетителя в таблицу добавляется запись, содержащая id поста, за который посетитель голосует и id посетителя.

Проверка будет очень простой.

В эту же таблицу можно и оценку посетителя вставить, минусанул (-1) или плюсанул (+1) он, тогда и суммарный рейтинг поста будет просто подсчитываться суммой оценок в этом поле.

Comments

[Ogra]

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

[Павел Чипак]

Вместо проверки лучше повесить уникальный индекс на поля post_id и user_id.

[rakot]

2Ogra: Суммарный рейтинг и другие сводные данные лучше хранить в отдельной таблице счетчиков. Чтобы не блокировать саму запись(в случае MyISAM таблицу) при изменении счетчика.

[Kir Shatrov]

@rakot А можно поподробней про блокировки при MyISAM? Не слышал раньше, а все таблички такие.

[Doktor_Gradus]

Практически в любой грамотной книге про mySQL написано про все используемые этой СУБД типы таблиц, начиная с ISAM в ранних версиях mySQL и заканчивая InnoDB, и про различия между ними. Разные типы таблиц могут даже по разному обрабатывать, например, автоинкрементное поле.

[rakot]

2RazoR_Empire: В этом нет никакого секрета, InnoDB при Update залочит запись над которой производится Update, MyISAM же залочит всю таблицу, что значит залочит и прочие технические процессы можно узнать в книге «High Performance MySQL, Second Edition» или в переводе «MySQL. Оптимизация производительности, 2-е издание».

[Kir Shatrov]

@Doktor_Gradus Хорошо, а как контролировать то, что в posts_users_rel только одна уникальная запись для опр. компании и данного юзера? Проверять отдельным запросом?

[Doktor_Gradus]

2RazoR_Empire: Да там выше уже написали — уникальный индекс на post_id+user_id

[Doktor_Gradus]

Тогда проверка не нужна будет, просто при попытке повторного голосования будет ошибка дублирования записи и новая запись не вставится. Можете либо обрабатывать ошибку, возвращаемую MySQL, либо ничего не делать.

Если интересует всё же проверка, то:

select count(*) AS rec_cnt FROM `posts_users_rel` WHERE `post_id`= my_post_id AND `user_id`= my_user_id

Этот запрос выполняется при формировании страницы с постом и если rec_cnt > 0, то стразу запрещать жать кнопку данному юзеру.

[rakot]

2RazoR_Empire: Сделайте user_id уникальным и запросик с инсёртом, но с допиской ON DUPLICATE KEY UPDATE post_count=post_count+1
мануальчик по этой штуке

Answer 2

[the_ghost]

у меня сделано так
таблица статей содержит поле avg_rate — в него мы пишем среднее значение голосов
таблица рейтинга — id статьи, qty — количество голосов, sum — сумма голосов

при голосовании за статью, мы:
1. добавляем 1 к полю qty в таблице рейтинга
2. добавляем оценку к полю суммы sum
3. выситываем среднее и пишем его в таблицу статей

Зачем писать? А чтобы потом было немного проще работать со статьями.