Вопрос заключется в том, как легче всего реализовать сабж на форуме.
Тобишь, как показать пользователю, в каких темах появились новые сообщения. Желательно, не применяя для реализации задачи отдельной таблицы БД. Нужно ли для этого установить cookie или специально их не устанавливать... Хотелось бы узнать алгоритм решения...

Куки-файлы от этого со временем могут распухнуть непомерно...
Мне в голову приходят только дополнительные таблицы
Как вариант - скачай бесплатный скрипт форума и посмотри, как там это реализовано.

Цитата(Bastet @ 20.10.2005, 22:24)

Мне в голову приходят только дополнительные таблицы

Хорошо, как по вашему мнению их можно оптимально использовать?
Вести статистику для каждой темы, в отдельном поле записывать id пользователей, её посетивших и сбрасывать список при появлении нового сообщения... Или ещё что-нибудь в этом роде ? Тогда поле конечно не переполнится, но сортировка инф-ии займёт уйму времени загрузки скрипта, как и любые аналогичные решения...

Цитата(Bastet @ 20.10.2005, 22:24)

Как вариант - скачай бесплатный скрипт форума и посмотри, как там это реализовано.

Не люблю капаться в чужом коде, хочу понять решение на уровне алгоритма...

Dandik

Знаю как сделать просто непрочитанные сообщения прочитанными, если юзер попадает на страницу то в таблице, в строке с его логином в поле read ставиш 1 (0 - непрочитано), от этого и пляши

Bastet

Цитата(Bastet @ 20.10.2005, 23:24)

Как вариант - скачай бесплатный скрипт форума и посмотри, как там это реализовано.

От этого голова распухне вместо кук

Цитата

Знаю как сделать просто непрочитанные сообщения прочитанными, если юзер попадает на страницу то в таблице, в строке с его логином в поле read ставиш 1 (0 - непрочитано), от этого и пляши

Хм, если ты говоришь о его логине, то можно предположить, что говоришь и о таблице всех пользователей со строкой характеризующей данного. Тогда, если у меня на форуме 100 непрочитанных сообщений, то данная одна 1-ка в поле для какого из этих 100 будет действовать ?? Или для всех сразу ? Одной такой 1-ой не обойтись в любом случае...
Хотя может, я тебя не правильно понял, разъясни поподробней...

Dandik

хм... тогда я даже незнаю, да, 1-ка для форума не подойдёт, т.к. топиков много и их количество может меняца, ну тогда попробуй куками. Т.е. если юзер прочитал топик пишеш ему куку что он прочитал, а в следущий раз удаляй старую куку и пиши новую

Оптимальный вариант.
1. Все что старее недели (к примеру) считается либюо все прочитанным, либо наоборот.
2. В поле БД в таблице пользователей пишется поле, куда заносишь прочитанные пользователем темы за период последней недели.

Цитата(Mal @ 22.10.2005, 09:30)

Оптимальный вариант. 1. Все что старее недели (к примеру) считается либюо все прочитанным, либо наоборот. 2. В поле БД в таблице пользователей пишется поле, куда заносишь прочитанные пользователем темы за период последней недели.

Нда, структура того же уровня, на которой я и остановился при решении задачи, только немного оптимальней:
Ведь т.к. перменной величиной в данной ситуации являтся тема, а не пользователь, то логичней было бы работать на стороне темы... По сему я выделил в каждой теме (ну и в форуме соответственно) поле, в которое записываю id посетевших её пользователей, при появлении нового сообщения, я это поле обнуляю... В принципе тоже самое, только если работать на стороне пользователя, то выцепление id обновлённой темы c последующим удалением из списка у каждого пользователя форума (которых может быть оччень много) потребовало бы уйму времени, впрочем это уже не важно... Просто думал, что может есть какой-либо другой способ. К тому же данный занимает немного временых ресурсов и меня в принипе устраивает.
Всем спасибки за ответы.

Куксикус, а никто не говорил, что будет легко. Программирование вообще наука не для средних умов.


Dandik, я представляю это так: есть таблица вида <id_пользователя, id_темы, дата_последнего_просмотра>. Когда пользователь читает тему, соответствующая запись обновляется. Спустя n-ное число недель с момента последнего просмотра записи убиваются.
У темы есть поле, в котором хранится дата последнего обновления (или не хранится, а вычисляется на основе даты последнего поста в ней).
Если дата последнего обновления в первой табличке меньше, чем дата обновления в теме, то топик помечается, как имеющий новые сообщения.

Такие вот мысли. Если что-то непонятно, попробую объяснить подробнее.
Насчет оптимальности варианта не знаю - только что сама придумала...

Bastet, попробуй вникнуть в мой способ (описано выше)... и сравни
Тут дело может быть в том, что:

Цитата

есть таблица вида

Дополнительная таблица для решения подобной задачи - непозволительая роскошь, со всеми вытикающими последствиями траты временых ресурсов (отдельныйе запросы, выборка и т.д.)

Цитата

вида <id_пользователя, id_темы, дата_последнего_просмотра>.

Размеры таблицы: кол-во пользователей * кол-во страниц, как-то жестоко это всё...
Вообщем мне, разумеется, всё понятно, просто постарайся вникнуть в мой пост предыдущий, ну или в предожение Mal Hack

Dandik,
возникае проблема:
как ты собираешься выбирать из базы новые темы? Сам-то такой способ очень хорош, но встаёт вопрос о быстродействии.
логичный вариант выборки - делать её с помощью LIKE
теперь представим, что тем много и, даже если сделать текстовый индекс, это вряд ли поможет в плане быстродействия

Цитата

Dandik, возникае проблема: как ты собираешься выбирать из базы новые темы? Сам-то такой способ очень хорош, но встаёт вопрос о быстродействии. логичный вариант выборки - делать её с помощью LIKE теперь представим, что тем много и, даже если сделать текстовый индекс, это вряд ли поможет в плане быстродействия

Хм, если ты находишься на стадии просмотра форумов, то необязательно проверять каждую тему форума, т.к. можно проверить (действительно используя оператор LIKE) поле, выделенное в таблице форумов... Ну а если поле такое создавать не хочешь, то я, например, определил время давности темы ( 2 недели ), если тема старше, то она не удостаивается просмотра и считается просмотренной для любого пользователя.
Если ты заходишь на форум, то достаточно будет проверить те темы, которые находятся на одной странице, максимум 20-25 тобишь...
Я не заметил большую мелительность скрипта из-за этого метода, как на локальном, так и на внешнем хосте...
Тут даже не в этом дело, просто по средствам данной темы я и хотел выяснить способ лучше... но никто ничего лучше не предложил, возожно у тебя есть вариант какой-нибудь?

Цитата

Тут даже не в этом дело, просто по средствам данной темы я и хотел выяснить способ лучше... но никто ничего лучше не предложил, возожно у тебя есть вариант какой-нибудь?

сейчас думаю над вариантом с дублированием данных о просмотренных темах в таблице пользователя. Возникает вопрос, для чего нужно дублирование?
просто возникла идея, вернее, пока только вопрос:
будет ли такой запрос:
SELECT ... WHERE thread_id NOT IN (идентификаторы просмотренных пользователем за период тем через запятую) ORDER BY .. -- оффсет с лимитом и т.д.
быстрее того, который с LIKE?

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

Гость_fastkill

Цитата

дублированием данных о просмотренных темах в таблице пользователя

Я уже говорил об этом... Дело в том, что тем всегда получается больше, чем пользователей, сл-но, если ты будешь работать на стороне таблицы пользователя, то поле индификаторов тем будет намого больше у пользователя... Более того, если ты будешь работать с индефикаторами (которые не несут в себе никакой информации о времени создания темы) ты не сможешь их удалять, а значит они будут только накапливаться. Т.е. Тема продёт и забудится, а пользователь будет в активности всегда и в его поле будет храниться инф-я о темах годовалой или более давности (с момента регистрации), каждый раз придётся перепроверять этот никому не нужный груз или реализовывать множество дополнительных запросов для обновления данного поля... Обновление же соответствующего поля на стороне темы очевидно, в момент добавления сообщения тема для всех становится обновлённой, а следоательно и поле обнуляется (Если говорить о поле пользователя , то такое радикальное обновление врят ли может быть спровацированно каким-либо действием)...

Цитата

NOT IN

Скорее всего быстрее, хотя сам я не проверял )

Довольно оптимальным будет текстовое поле в профиле пользователя, размером этак в 2^16 символов + числовое поле в которое записываем идентификатор якоря поста/сообщения. Якорь это самое старое сообщение(скорее всего самое первое на ресурсе).

Каждое сообщение имеет свой идентификатор, с каждым новым сообщением идентификатор увеличиваеться, ID удалённого сообщения не используеться по новой. Это нормальная работа MySQL (и по моему большинства других) БД.

Текстовое поле представляем огроменным битовым полем, где каждый символ это 7 бит, тогда уложимся только в читабельные символы.

Берём id проверяемого сообщения, отнимаем id якоря, делим нацело 7(символ), остаток(номер бита). Проверяем бит, установлен - значит прочитанно.

Естественно текстовое поле не должно быть забито символами, оно растёт постепенно вместе с количеством постов на ресурсе. Спустя время длинную строку сложней обновлять для БД, но всё равно это будет эффективней чем держать списки идентификаторов для каждого пользователя. Да к тому же можно плевать на точность и сдвигать якорь каждые два месяца, одновременно обрезая строку с битами.

Не видел пока ещё реализации этой идеи