в IPB алгорим, который я описал выше. Но в отличии от моей реализации (две таблицы - маркеры форумов и маркеры тем) там в таблице пользователей есть поле типа text, в котором хранится рассерилизованный массив, в катором хранятся маркеры для этого пользователя. Мне такой способ хранения показался на редкость э.. нехорошим, сделал дополнительными таблицами. "Ложных срабатываний" нет, можно без проблем (парой несложных запросов) обрезать старые маркеры (я поставил авточтение на 3 месяца), что и делается в кроне раз в неделю
Кстати, я на работе щас какраз модифицирую метод, по которому у меня было реализовано до этого, так что доделаю, поделюсь результатами
armadillo Итог таков а). Тотальное правильное слежение за всеми темами: 1 тема = 1 запись о прочтении. Облегчается удалением старых тем или переносом их в архив с удалением данных о прочтении. Таков механизм и оставили. б). Частичное слежение - всякие ухищрения: смотрим по времени последнего логина по сравнению с временем постинга, запоминаем во время жизни сессии прочтённое, ограниченное кол-во правильных слежений, подписка на слежение и.т.д. Обычно приходится комбинировать несколько методов, довольно тяжко отдебагать до нормальной работы. Покрайней мере я не довел до 100% работоспособности т.к. решили оставить вариант А.
в общем случае время логина не связано с прочтением конкретной темы. Тогда уж время последней сессии есть время нажатия кнопки "все прочтено". хотя тут так реализовано. а тотальный где используется?
armadillo Насколько я знаю, больше никто не реализовывал такой подход тотального слежения на живом проэкте. Посмотреть можно тут http://groups.boomtime.lv однако сами понимаете, нужно зарегатся, а регистрация только для Латвии по номерам мобильных телефонов LV. На iXBT форуме сделано так, что необходимо подписатся на слежение + максимум 250 тем.
ну во первых это ограничение по объему сразу)), а во вторых такой вариант или даже нечитанные темы пишем?
armadillo Типа того, я такое пытался сделать. если честно, мозг вскипел на сложности ифов и так отдебагить до конца не удалось (ну точнее не дали, что-бы тратил рабочее время на более полезные вещи, но это не столь важно). Горбунов Олег Ждём идею, хотя если честно, честного и одновременно лёгкого в плане объёма базы слежения толком сделать нельзя. Всегда идёт или много данных и производительность либо компромисы.
armadillo Да, только так можно определить что если человек нажал "Отметить всё как прочитанное" то перекинуть его именно на то сообщение, которое было первое в теме после нажатия кнопки.
armadillo На каждый форум надо по своей записи тогда, т.к. отметить можно одну ветку форума, а можно весь. Могут отметить 3-4 из всех (а это может быть 20-30 веток). Да, данных будет меньше, но и таблиц будет уже не одна а две + логика проверок сразу усложняется. Оговорюсь, что у меня проверка происходит по ID сообщений а не по датам. возможно это мой ляп, но другого форума я уже не делал, а этот работает уже довольно долго да и я уже там не работаю
"отметить ВСЕ" - это отметить все. Отметить прочитанным частично - это тоже самое что просмотреть их руками. Совсем нечитанные, пусть их там 100 000, зачем отмечать? у сообщений все равно есть дата, можно для каждого юзера хранить ОДНУ дату нажатия "все прочел" или по одной на каждый раздел (ну 50 штук).
armadillo Я уже написал, что это конкретное решение, которое уже так легко не переделать и там проблема захламления таблиц решена. Да, твой вариант хороший, можно вполне использовать.
Хм... А не вариант хранить в базе только последнее посищение темы? А есть ли новые сообщения, или нет выводить если дата_когда_юзер_зашел > дата_когда_юзер_посищял_тему?
Горбунов Олег А почему, собсно? В vB именно так и сделано. Побочных эффектов не наблюдается. Если кто-то зашел на форум и просмотрел только часть тем, впоследствии они пометятся как прочитанные - но это не мешает нисколько, эффект накапливания непрочитанных тем в том же SMF гораздо неприятнее. В пределах одной сессии набор прочитанных тем хранится у клиента в куках (или в сессии), таких тем не может быть много, так что проблем не возникает.
Dagdamor, потому что тема была затеяна с желанием отойти от данного решения. Ибо оно не оптимально, и не полноценно.
Горбунов Олег Имхо, то, что вы изобретаете, может и достойно слов "оптимально" и "полноценно", но мало кому нужно на практике Хотя как гимнастика для ума, чисто теоретическая задача - интересно.
Dagdamor, неправ - то что достойно слов - "оптимально" и "полноценно" , очень нужно на практике ... громоздкие реализации сейчас в почете, но всетаки стоит стремится к элегантным и полноценным решениям (очень хочется что бы оно было простое - но очень боялся применять это слово к разрабатываемому алгоритму). А Оптимальность вершина исскуства ;-) ...
дело не в оптимальности, дело в банальной юзабельности. я предпочитаю заходить на форумы в разное время, с разных компьютеров, прочитывать некоторые темки, и чтобы даже через неделю непрочитанные темы подсвечивались. вот ради этого и было создана тема
[археолог моде он] читаю, не могу понять в чем была проблема для обсуждения. )) подкиньте еще задачку какую-нибудь?
пример форум 100 разделов, 100к юзеров, 100к тем, 5м постов. Задача: показать нечитанные разделы и ветки. есть кросс-таблица юзер-читанные ветки. есть кросс-таблица юзер-читанные разделы. us_id,f_id,t_unread_count,last_time_read у юзера хранится дата последнего "все прочтено" при нажатии на все прочтено - убиваются все связи юзер-ветка и юзер-раздел. при прочтении ветки юзером: us2post добавляется/обновляется связь юзер-ветка со временем просмотра. us2forums t_unread_count-- where f_id=$f_id and us_id=$us_id if (t_unread_count==0) last_time_read=now() t_unread_count придется мониторить при удалении/переносе тем. при удалении постов может давать "ложные" срабатывания. в каких-то случаях (может том же удалении) будет требовать пересчета. при добавлении поста: us2post убиваются связи всех юзеров с этой веткой. us2forums update us2f set t_unread_count++ where f_id=$f_id and last_time_read>$PrevTopicTime надо как-то придумать сбрасывать (удалять связи) us2f при длительном непросмотре раздела юзером (при оставлении данных в us2p) t_unread_count тогда будет считаться за период. возможно кроном (В punbb вроде и архив создан "прозрачный") может хранить дату последнего просмотра любой темы в разделе. при добавлении новых постов в старую ветку - из us2p берутся данные куда кидать юзера Недостаток - объем таблицы u2f = миллионы записей (без сброса старых данных, с ним немного). достоинство - чтение из нее быстрое безо всяких подзапросов. все обновления связей по просмотру выполняются уже ПОСЛЕ отдачи страницы юзеру и влияют (несильно) на общую загрузку сервера, но не на время конкретной страницы. самые тяжелые вещи - удаления/переносы, добавления постов легче. Отдельная задача - показать изменения с последнего посещения, но она проще.