Нашел ужасный код в двиге JohnCMS5

по поводу форума и прочих модулей, они просто не много изменились, принципов не менялось, там по сути все еще как в тройке

Koenig, да вот просто не знал как оно себя поведет.

Ну и если тут пошла тема об оптимизации, то почему бы не сделать ограничение хранения записей в таблице cms_forum_rdm. Недавно была очень сложная ситуация на аннимоне. Переносил базу и оказалось что в этой таблице около полутора миллионов! записей. Мало того что эта таблица занимала половину обьема всей базы, так и не заливалась вообще, никакими скриптами и тем более пыхадмином (я наконец понял почему после каждого переезда тут всегда сбрасывались непрочитанные). В итоге пришлось сделать ограничение для непрочитанного в форуме - оно показывается не за все время, а за 7 дней (темы которые юзер 7 дней не читал автоматом становятся прочитанными). Все записи что старше - удаляются при автоочистке. Первое время было много возмущений, но все же эффект получился значительный, больше 8 тысяч записей в cms_forum_rdm еще не было.

# web_demon (01.10.2013 / 17:29)
Все равно останется еще половина

INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6),(...),(...),(...),(...)
ON DUPLICATE KEY UPDATE c=VALUES(a);
Ну так например

Krite, вполне себе вариант, надо будет проверить

# NURD (01.10.2013 / 17:12)
Это же ппц. Ну вот пара человек на слабеньком хостинге отмечают 200 непрочитанных тем.
Математика:
10 * ((200 * 2) + 2) = 4020

Объясняю цифры:
10 - человек
200 - непрочитанных тем
...*2 - цикл

На слабеньком хосте сайтов посещаемых мало, да и старый оставит всё как есть=) хотя не, лет через 7 когда форум заменить решит может и переделает запросы

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

Krite, Да даже и подтверждение по мылу не спасет, если уже на то пошло. Есть куча сервисов по выдаче временных ящиков. Ладно, это лучше трогать не надо, а то начнутся потом такие "атаки")

# web_demon (01.10.2013 / 17:29)
И если будет под тысячу апдейтов, то это IN('" . implode(',',$array) . "') разрастется до безумных размеров. Я как-то раньше побоялся это использовать.

Вот имено это и важно
Более того, у mySQL есть ограничение на число подобных операций.
---
Дело в том, что когда ты все пробуешь локально, где на тестовом форуме всего то 5-10 постов, почти любая абракадабра будет работать очень быстро.

# Tor (01.10.2013 / 17:41)
NURD, А эту тему создал чисто поржать,да?

Да, NURD за это должен отхватить неиллюзорных

А вообще, фигней маетесь в данной теме и я щас объясню почему...
---
Сами помните, откуда у JohnCMS растут ноги, такова уж была структура.
Точнее, было вообще ППЦ краткое, все в 1-й таблице и к примеру, еще в 2008 году, когда на Газене было то всего около 10 тысяч постов на форуме, двиг полностью вешал VDS...
Пришлось срочно писать костыль. который вылился в отдельную таблицу cms_forum_rdm
---
Самый правильный метод - это систематизация (разбивка) таблиц.
Структура -> топики -> посты.
В этом случае, при любом постинге, обновляется метка в поле таблицы топиков.
А уже потом, когда вычисляешь, прочитано, или нет, ты сверяешься только с таблицей топиков. число записей в которой на несколько порядков меньше, чем в таблице постов. Посему, операция проходит весьма быстро.