Как правильно организовать рейтинг записей?

Question

[nezzard]

Помогите советом как правильно организовать таблице для рейтинга записей и комментариев.
Есть запись, человек может сделать + или -, нужно чтобы человек мог переголосовать если ему это нужно, отсюда вытекает что нужно заносить его выбор в базу данных.
Я очень переживаю из за нагрузки, при проверки, за что голосовал и что выбрал.
На данный момент у меня при голосовании есть общий рейтинг записи который работает так
общий рейтинг + текущий
и есть строка с id юзеров через запятую

Если вносить значение +1 -1 через запятую в другую строчку, то на сколько требовательным будет цикл, если допустим у записи 10 комментариев и 500 проголосовавших ?

Или как правильно организовать таблицу с выбранными значениями пользователей?

Answer 1

[Александр Кубинцев]

Я тоже за обобщение рейтинговых объектов.
То есть, допустим у вас есть Article и Comment. Введём объект RatingEntity c результирующим рейтингом и добавим связь с ним 1-к-1 для Article и Comment ratingEntityId. Таким образом таблицы будут выглядеть так:

rating_entities
------------
id | rating_sum

articles
------------
id | rating_entity_id | ...

comments
------------
id | rating_entity_id | ...

Далее делаем Rating такого вида:

ratings
------------
id | rating_entity_id | user_id | value

где будет составной ключ (rating_entity_id + user_id), а value иметь значения +/- 1.

Что касается производительности, то проблемы не вижу. Дело в том, что при голосовании очевидно, что нужно показать текущий рейтинг +/- 1, что можно сделать средствами frontend. То есть можно послать запрос на сервер и не ждать ответа.
Обновлять результирующий рейтинг можно через триггер в БД.

Answer 2

[Максим Гречушников]

комментарии
comment_id, user_id, text, rate_count, rate_sum......

пользователи
user_id, name ....

рейтинги
id, comment_id, user_id, value (1, -1)

SELECT *, (rate_sum/rate_count) as rate FROM comments WHERE article_id=1
проверить проголосовал ли человек пожно по таблице рейтинги
при добавлении рейтинга в таблицу, пересчитываете для данного комментария занова рейтинг и записываете в таблицу комментария кол-во проголосовавших и общую сумму рейтинга. либо сразу конечную цифру рейтинга

Answer 3

[deleted-tnorman]

Первое что в голову пришло

У вас должен быть какой-то общий тип id для всех сущностей, за которые можно голосовать, тогда вам надо хранить в пользователе путь к списку всех сущностей за которые он отдал голос, конечно со значением 0:1
тогда в момент подгрузки списка комментариев и сообщения для какого-то отдельного пользователя вы можете обращаться к списку и уточнять, может ли этот пользователь проголосовать\переголосовать.
А в противном случае там висит общее значение прикрученное к комментарию или посту или что там ещё.