Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 След.
RSS
Пишем свой форум, принцип отметки о прочтении
 
Вопщем дело такое, пишу свой форум. Всё замечательно, но столкнулся с таким делом. что при заходе авторизирвоанного юзверя на форум нужно помечать темы в которых есть не прочитанные сообщение. В принципе как сейчас на всех известных движках. Т.е. показать какие сообщения ещё не прочитаны. Но как это реализовать в базе данных? Т.е. по какому вообще принципу такое можно выдумать и сделать?

Была идея сделать таблицу по такому принципу:

id юзверя     id сообщения не прочитанного
----------------|---------------------------------------------|
        1          |23,89,100                                          |

Т.е: 1 - уникальынй id юзверя, а 23,89,100 - это уникальыне id сообщений которые перечисляются через запятую.
Т.е. когда кто-то создаёт тему то при сохранении скрипт пробегается по всей базе юзверей и вписывает id нового сообщения в этот список. По сути, реализовать не сложно, но когда пользователей будет очень много, то это будет убийственно для сервака - переписать данные во всех базах юзверей. Или не помрёт? Может есть более рациональный выход? :)
 
Мне было бы тоже интересно послушать возможные варианты решения.
 
Некоторые программеры давали такие советы как:
в печенье юзверя записывать id темы последней которую он прочитал, ведь в базе у тем уникальный id по возрастанию идёт, идея не плохая, что при следующем заходе скрипт высчитывает от id из печенья темы которые больше этого числа и помечает их не прочтёнными, НО, он может прочитать не все или же в разброс и тогда некоторые темы которые ещё ен просмотрены будут помечены как просмотренные - это не true, так что идём дальше думать :) Если перспективный вариант решения найдётся я отпишусь для кого-нибудь на будущее :))
 
Идея в том, чтобы все прочитанные темы данного пользователя хранить в каком либо хранилище.
А таковых может быть два - либо COOKIE либо БД
При чем с куками наверно проще всего будет, и, похоже в большинстве случаев сделано имеено так. А чтобы не перезагружать броузер куками, то устанавливать срок жизни куков нужно не слишком большим, например неделя-две (в зависимости от того, как быстро тему уходят на предыдущие странички).
Тогда непрочитанные темы вновь будут подсвечены как новые но если они будут на третей-четвертой страницы - то ведь ничего страшного, врядли юзер туда заглянет.

Аналогичное ограничение по времени можно реализовать и в случае храниния прочитанных тем в БД.
 
Недопонял что-то твоего варианта :)
 
Ну, если тема прочитана, ставишь в куках
setcookie("READED_123", "1");
где, 123 - id темы.
далее, при генерации списка тем, если $_COOKIE["READED_123"]==1 то не подвечиваешь тему #123 как непрочитанную, иначе подсвечиваешь. Так для каждой темы.
 
Phoenix, а двухкилобайтное ограничение на длину куки идёт лесом? :)

Всё-таки прежде чем спрашивать, лучше посмотреть решение грамотных людей - насколько мне известно заводят специальную таблицу связи topic / user.
 
Рассматривал очень много решений грамотных людей, на многих форумах и блогах читал, в основном все предлагают идеи хранить в таблицах у каждого уюзверя какие он темы прочел или же наоборот не прочёл - не удобно это, а не удобно тем, что нагрузка большая будет если активность высокая и весить достаточно много будет... Сами подумайте, если на форуме будет, скажем 10 000 человек, кто-то создал сообщение и id этого сообщения должно прописатсья в каждой таблице этих 10 тысяч юзверей, вам не кажется что многовато?
 
Цитата
.cens пишет:
Phoenix, а двухкилобайтное ограничение на длину куки идёт лесом? С улыбкой
Потому я и говорил, ограничивать срок жизни куков по датам...
на десятков пять тем этих двух килобайт вполне хватит.
 
Если хранить в БД, зачем при создании пользователя прописывать для всех юзерей данные в табличку. Просто прими за основу, что если записи в табличке нет, то значит ема для данного юзера новая.
А в БД значения меняй при прочтении тем.
 
а как же разрастание таблички с ростом кол-ва тем?
 
JUmPER, сделать в табличке поле view_date и убивать записи если они старше... мм... предположим года. вообще mysql работал у меня и с таблицами с миллионом записей. главное правильно выставить ключи индексации.
 
Юзверей много- нагрузка будет пока будем каждого в таблицах прописывать
 
Dollor, на пхпбб не помню какой-то версии я видел по 80 sql запросов на рендер страницы. разница если к 80 селектам добавится один инсёрт или селект думаю всё же не существенна. В самописном форуме 80 запросов это космос, что в общем-то хорошо.. но надо тестить.
 
Эмуль сайта, практикуйтесь http://denwer.ru
 
DDoS, о существовании денвера все знают давно - это раз, а два речь не об этом. Практиковать каким образом? вручную тыкаться и создавать несколько тысяч юзверей и тем, чтобы потом протестить как сервак отреагирует на подобные способы рабоыт? :) Не думаю не то :)
 
Цитата
Dollor пишет:
Была идея сделать таблицу по такому принципу:

id юзверя id сообщения не прочитанного----------------|---------------------------------------------|1 |23,89,100 |

Т.е: 1 - уникальынй id юзверя, а 23,89,100 - это уникальыне id сообщений которые перечисляются через запятую.Т.е. когда кто-то создаёт тему то при сохранении скрипт пробегается по всей базе юзверей и вписывает id нового сообщения в этот список. По сути, реализовать не сложно, но когда пользователей будет очень много, то это будет убийственно для сервака - переписать данные во всех базах юзверей. Или не помрёт? Может есть более рациональный выход?

Чет я не понял, а зачем пробегаться по всей базе пользователей, при создании темы  :o Допустим в таблице users, есть поле, в которе вписывается id темы которую пользователь прочитал, вписываем через запятую, при входе сравниваются id тем на странице с массивом в поле юзера, если не найдено значит тема новая! Тогда встает вопрос, по разрастанию тем и собственно данного поля для каждого юзера... как вариант можно поэксперементировать с датами, типа удалять старые id, что меньше определенного id, который явлется точкой отсчета, надо обдумать интересная тема поднялась)))
 
Цитата
Dollor пишет:
DDoS, о существовании денвера все знают давно - это раз, а два речь не об этом. Практиковать каким образом? вручную тыкаться и создавать несколько тысяч юзверей и тем, чтобы потом протестить как сервак отреагирует на подобные способы рабоыт?Не думаю не то
Думаю не все знают про денвер
 
Цитата
на пхпбб не помню какой-то версии я видел по 80 sql запросов на рендер страницы. разница если к 80 селектам добавится один инсёрт или селект думаю всё же не существенна
а как же блокировки при записи? - можно так производительность на порядок снизить...

Цитата
Допустим в таблице users, есть поле, в которе вписывается id темы которую пользователь прочитал, вписываем через запятую, при входе сравниваются id тем на странице с массивом в поле юзера, если не найдено значит тема новая!
это ещё хуже:
- неизвестен размер поля;
- его нужно самостоятельно разбивать и сравнивать - т.е. тут вся нагрузка на скрипт (если вёб-сервет и субд на одной машине, то такое лечение только во вред).
 
JUmPER, блокировки при записи в КУДА? в таблицу именно с этой связью. проблемы быть не должно.
2 запроса в псевдокоде:
Код
'insert into user_topic(user_id, topic_id, date) ($user_id, $topic_id, NOW()'
'select 1 from user_topic where user_id=$user_id'


на счёт варианта хранить строку со списком просмотренных тем, возникает ограничение на макс длину строки 65К. Разбивать-то не надо, достаточно
Код
select 1 from user where user_id=$userid and read_topic like '%,$topic_id,%'

да и при в ставке проблем не будет. но 65К. :) Тогда табличка будет короче, но при селекте будет строковая операция, так что нужно чтобы при селекте выше сначала проверялся идентификатор пользователя.
Страницы: 1 2 След.
Читают тему