"фаворитные списки" *в форумах - за и против

[mar]

"фаворитные списки" - это не я так обозвала, это пользователь один на форуме предложил.
Суть в следующем:
был некий форум, который раньше был один, а теперь мне заказали скрипт и админы получили возможность форумы на нем плодить (тематическике, как тут, например).
Весь старый форум перелили в тематический форум "архив" и сделали его только для чтения и пооткрывли ряд новых по темам.
Открылись, народ зашел, огляделся и стал писать свои предложения.
Вот "фаворитные списки" - одно из них. То есть я так понимаю, что он хотел бы иметь возможностях в любых тематических форумах поотмечать себе любимые темы и получить еще один виртуальный форум favorites.
Хотелось бы выслушать мысли за и против такой идеи (как с точки зрения "бизнес-логики" форумов в целом, так и с точки зрения претворения в жизнь (те возможных проблем со скоростью работы)

[ran71me3rr0r]

А что, форум по избранным темам это даже очень рульно!

[mar]

ran71me3rr0r
спасибо, а поподробнее можно? (или просто идея понравилась?) :)

[Prisoner]

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

[mar]

собственно меня беспокоит следующее: база форума на MySQL (со всеми вытекающими отсюда ограничениями :( )
имееются таблицы:  
forums (id, name и прочее)
forum_topics(id, forum_id, name и прочее)
topic_messages(id, topic_id, name и прочее)
users(id, username и т.д.)
Для того, чтобы мне юзеру задать  favorites, надо где-то (неважно где, но положим в отдельной таблице, чтобы не нагружать users, или, может быть прямо в ней) сделать поле, куда запихивать id всех отмеченных  им по всем форумам тем (forum_topics). Cудя по всему, это долен быть тип set (те массив) Грубо говоря, индивидуальный виртуальный форум  favorites - это связка id юзера - массив id topic_messages
Дальше начинается "НО":
На сегодняшний день в форуме  3341 тема.  Они набрались меньше, чем за год. Причем за следующий их будет явно сильно больше (во-первых, хозяева об этом очень сильно заботятся, во-вторых прошлый вариант работал очень медленно, что отпугивало посетителей (собственно, поэтому меня и попросили им форум написать). Вывод - что же это будет за монстр - индивидуальный виртуальный форум для каждого юзера, применительно к базе данных и запросам :(( ? (понятно, что тысячи ссылок человек, скорей всего, не отметит. А вдруг отметит ;)

[ran71me3rr0r]

mar
спасибо, а поподробнее можно? (или просто идея понравилась?)
.. идея понравилась :)

[Prisoner]

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

[mar]

Prisoner
тоже вариант :)
а еще какие идеи будут?

[Prisoner]

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

[mar]

Prisoner
не знаю. Если нормально организовать данные, то выбор на лету не должен занимать много времени (не больше, чем при выводе список тем любого другого реального форума)

в принципе с set - это я хватанула. Только 64 элемента в массиве - мало. Можно в принципе просто тупую таблицу создать типа:
id -- id юзера (не уникально, может повторяться)
topic_id -- id выбранной темы
с индексом по тому и по другому
а потом просто:

SELECT v.id, ft.name
FROM virtual v,  forum_topics ft
WHERE v.topic_id=ft.id AND
            v.id = номер id нашего юзера
ORDER BY ft.name; -- (те сортировать все это добро по алфавиту)
           
А дальше работать с этим, как с обычным списком тем за одним исключением - нельзя создавать новую тему (тк нет реального номера (id) форума)
А в другие (открытые для записи, конечно) можно постить - они лягут на место и все остальные, и этот юзер в том числе увидит новые сообщения и в обычных форумах.

[Prisoner]

В общем-то - да! Но вы просили идей, а их у нас есть :).

[mar]

Prisoner
:up:
Ну, мне еще и поразбираться хотелось. Вместе веселей думается :)

[Prisoner]

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

[mar]

Prisoner
Смоделировать-то конечно можно (еще один скрипт). Но эксперименты ставить на чужем  боевом сервере, пожалуй, не буду :biglaugh:
Но задуматься стоит. Вернее почитать про возможности mysql.
Придумаю - напишу  :biglaugh:
Если серьезно, то нагрузка только в одновременном select-e о котором я уже писала, причем туда еще limit 0, 15 надо вставить: (ну, или следующие страницы 0 все равно по 15 штук)

SELECT v.id, ft.name FROM virtual v,  forum_topics ft
WHERE v.topic_id=ft.id AND              
v.id = номер id нашего юзера
ORDER BY ft.name
LIMIT 0,15;

А число выбранных тем у юзера вообще может прямо цифрой в таблице user-ов лежать.

В принципе это не намного хуже, чем одновременный просмотр тем же куоличеством юзеров самих форумов. (Или я чего-то не понимаю?)

[Prisoner]

Угу... я право не знаю чего мы заморочились - запросы-то почти идентичны...