Добрый день. Подскажите пожалуйста как реализуется алгоритм создания рейтинга статьи, блога и т.д. Например, есть блог, за него зарегистрированный пользователь может проголосовать: поставить + или - к рейтингу статьи... Подобно скрипту голосования, в данном случае ведь нужно учитывать то, чтобы один пользователь мог только единожды проголосовать за один блог. Становится вопрос о том как следить за этим? Я думаю можно сделать отдельную базу рейтинга, в которой будут поля айди блога, айди пользователя и голос + иди -. Она будет использоваться при подсчете голосов и определения голосовал пользователь или еще нет. В самой таблице блога также будет поле для рейтинга, уже с учетом разницы отрицательных и положительных голосов. Но думаю, что это не самое лучшее решение для сайта с хорошей посещаемостью, хотел бы спросить советов как вы реализовывали рейтинг в своих больших проектах. :wink: Заранее всем спасибо.
В таблицу блога добавить поля plus и minus, можно еще count_vote. При голосовании делать +1 в одно из полей. И чтобы пользователь голосовал единожды - завести табличку: id_blog, id_user
И алгоритм составить смогу, и код написать думаю тоже. Только хотел бы спросить совета как сделать правильнее? Моя логика верна была нет?
Алгоритм такой: есть таблицп статей, в ней два поля - rating и rateUsers в rating записывается текущий рейтинг, а в rateUsers через запятую пишите ид пользователей, при голосовании пользователя, делайте так: Код (Text): $rateUsersAr = explode(';', $row['rateUsers']); if(!in_array($userID, $rateUsersAr)) // все ок else // вы уже голосовати вот и все
5к это ерунда. Проблемы начнуться когда пользователей будет пару миллионов. Но это решение будет одним из лучших. Поскольку масштабировать БД много сложнее чем сделать ферму для PHP скриптов.А эту строку можно будет еще и упаковать для хранения в БД
Simpliest по твоему, или вашему, эксплод с запросом на текст будет быстрее простого запроса по двум полям и окупится масштабируемостью при любом количестве пользователей?
А вот с я стормозил. От БД в таком случае надо отказываться вовсе. не будет быстрее. Точнее в некоторых случаях может и будет быстрее, но это неважно. Важно что часть времени поиска по базе ляжет на скрипт и отдельное железо
Simpliest ну не знаю, мне лично вообще идеи с сериализацией идов в одно поле не нравятся, хотя я где-то сделал именно так, не помню уже...
Simpliest уже с 5к будут проблемы, и по памяти, и по производительности. При выводе нескольких статей на каждую нужно проверять вхождение id для текущего юзера (может ли он за нее голосовать).
Я бы завел отдельную таблицу: vote_id | vote_item | vote_type | vote_user | vote_power И таскал бы для статьи сумму vote_power vote_type — для расширяемости, т.к. потом рейтинг захочется не только к постам в блоге прикрутить. Так же, как вариант, хранить вместе с пользователем его последние 10-15 голосов, чтобы лишний раз не проверять в базе, голосовал или нет юзер за статью. Да и для старых статей голосование можно отключать, например.
Привет всем, это мой первый пост! я начинающий пхп программист, раннее неначем не програмил ) буду с Вами дружить --- по теме --- считаю что правильней будет иметь отделбную таблицу с вотерами(те кто оставлял голос) поля к примеру такие : 1. id опроса в котором голосовал 2. ip с которого голосовал 3. дата голосования ( time(); ) 4. id варианта который выбрал голосующий 5. id юзверя когда юзер заходит в опрос которому при создании был присвоен ИД 25, происходит проверка: select * from voters where id_vote = 25 после того как собралась инфа о всех вотерах кто проголосовал в опросе под id 25 проверяем на наличие голосов самого юзверя, думаю пример запроса нет смысла приводить! дальше если был голос 1, или два ... то запретить голосовать если же небыло голосов то вывести форму для голосования ! ------------------ этот вариант самый оптимальный и гибкий, такой же метод используется в том же Invision power board форуме =) наверно и в остальных крупнейших форумах !
эм прогнал, читал тему в час ночи уже сонный ) суть не меняется ) всё равно учет лучше вести в отдельной таблице ) Хранить данные массивом тоже можно но не гибко потом с этим работать, я такое применял но только в отдельных случаев где не нужно делать проверкии т.д, только хранить строго 20 значений которые уже иенялись! экономия на запросах ))
В алгоритме - в смысле "как сделать" - для рейтинга смысла нет. Это всё просто, ну, не для Simpliest, которого совсем уж увело в дали-дальнии. Дима Смирнов задаётся, наверное, единственным вопросом, который вообще стоит поднимать при "придумывании" рейтинга.