AlkatraZ, от этого там записей меньше не станет. Как на один топик соответствовало по несколько десятков записей в cms_forum_rdm так и будет. И храниться они там будут целую вечность
# web_demon (01.10.2013 / 18:46)
AlkatraZ, от этого там записей меньше не станет. Как на один топик соответствовало по несколько десятков записей в cms_forum_rdm так и будет.
А этого не избежишь.
Тут подписка один-ко многим.
если придумаешь что-то новое, будешь кандидат на нобелевскую премию по математике
---
Минимальное, что мы можем сделать - это привязать прочитанное к таблице топиков.
Можно правда еще больше извратиться, если при посте обновлять метки времени каскадом до корня...
В этом случае можно начать с таблицы категорий и далее, принимать в рассмотрение только те категории, где были изменения...
Но тут к сожалению одним запросом тоже не обойдешься, более того, возникает пусть и небольшая, но рекурсия...
# web_demon (01.10.2013 / 18:46)
AlkatraZ, от этого там записей меньше не станет. Как на один топик соответствовало по несколько десятков записей в cms_forum_rdm так и будет.
Записей то меньше не станет, но зато ты будешь гулять по индексам не всего форума, где может быть весьма много записей. а только по таблице топиков.
Это на несколько порядков меньше нагрузка.
AlkatraZ,
http://johncms.com/forum/index ... 35024
Ну как вот тут и есть предложение.
Ограничить некоторым временем, к примеру, я у себя сделал 7 дней. То-бишь через 7 дней топик автоматом становится прочитанным, а автоочистка движка удаляет все записи старше 7 дней в этой несчастной таблице.
Ниже измененный запрос. Переделать много ума не надо, добавить `forum`.`time` > '".($realtime - (7 * 24 * 3600))."' во все запросы работающие с этой таблицей.
$req = mysql_query("SELECT * FROM `forum`
LEFT JOIN `cms_forum_rdm` ON `forum`.`id` = `cms_forum_rdm`.`topic_id` AND `cms_forum_rdm`.`user_id` = '" . $user_id . "'
WHERE `forum`.`type`='t'" .
($rights >= 7 ? "" : " AND `forum`.`close` != '1'") .
"
AND (`cms_forum_rdm`.`topic_id` Is Null
OR `forum`.`time` > `cms_forum_rdm`.`time`) AND `forum`.`time` > '".($realtime - (7 * 24 * 3600))."'
ORDER BY `forum`.`time` DESC
LIMIT " . $start . "," . $kmess);
(чуть что код аж из тройки)
# web_demon (01.10.2013 / 18:59)
Ну как вот тут и есть предложение.
Ограничить некоторым временем, к примеру, я у себя сделал 7 дней. То-бишь через 7 дней топик автоматом становится прочитанным, а автоочистка движка удаляет все запи
Предложение очень хорошее и дельное.
К примеру, посты 7 и более дней давности нафигненужны.
---
Это может реально разгрузить таблицу cms_forum_rdm, но к сожалению не избавит от другой беды, просмотра огромного индекса всей таблицы форума.
Есть еще одна беда...
К примеру у нас, где в день сотни постов, недельная давность реально не нужна.
Но вот на мелких форумах. даже пост месячной давности может оказаться полезным.
---
Тут все таки лучше брать за основу то, как сделано на основных популярных WEB форумах, ибо там обкатано годами.
Да, мы тоже не вчера родились и у нас тоже наработка уже более 5 лет гг. Но как я уже писал выше, нужны не костыли, а разбивка таблиц.
AlkatraZ, Ну, думаю даже на маленьком сайте можно за неделю зайти в тему, тем более что раз сайт маленький, то и самих непрочитанных тем будет немного.
Тут все таки лучше брать за основу то, как сделано на основных популярных WEB форумах, ибо там обкатано годами.
Не буду говорить за всех, но мне нынешняя система очень нравится, даже более того это лучшее что я когда либо видел. И если действительно проработать некоторые моменты как с этой таблицей и ситуацией, которую описывал топикстартер, можно получить конфетку, которая будет работать вне зависимости от нагруженности сайта.
# AlkatraZ (01.10.2013 / 18:52)
Записей то меньше не станет, но зато ты будешь гулять по индексам не всего форума, где может быть весьма много записей. а только по таблице топиков.
Это на несколько порядков меньше нагрузка.
Это будет сразу даблкилл. Да, мускулу не надо будет проходить по огромному индексу. Плюс можно будет джоинить топики с разделами, а это минус куча запросов в цикле в том же непрочитанном, когда необходимо узнать название раздела в котором находиться топик и тд.
# web_demon (01.10.2013 / 20:04)
Плюс можно будет джоинить топики с разделами, а это минус куча запросов в цикле в том же непрочитанном, когда необходимо узнать название раздела в котором находиться топик и тд.
Куча запросов решается парой вставок. Что тебе мешает собрать один более крупный запрос и потом его отправить? Никаких сложностей.
Да и не парьтесь на счёт большого количества записей в БД.
Вот например обычный селект из таблицы в которой 3.2 млн записей.
http://prntscr.com/1un7tk
Как видно Mysql не напрягся.
Поиск по полю типа VARCHAR с использованием LIKE %%
http://prntscr.com/1un8qq
Как видно скорость не особо изменилась.
Скорость поиска по числовым проиндексированным полям да ещё и если там уникальные все элементы будет намного выше)
# AlkatraZ (01.10.2013 / 18:33)
Да, NURD за это должен отхватить неиллюзорных 
Я еще и на говнокод.ру запостю.
