Вы не зашли.
Небольшое сравнение возможно нового алгоритма работы в сравнении с прошлым.
Дано:
таблица _news - 82322 записи, 180 Mb
таблица _news_map - 172668 записи, 1.5 Mb
Старый запрос.
SELECT SQL_NO_CACHE *
FROM 2z_news
WHERE (
(
catid
REGEXP '[[:<:]](16)[[:>:]]'
)
OR (
catid
REGEXP '[[:<:]](8)[[:>:]]'
)
)
ORDER BY postdate DESC
LIMIT 0 , 30
Время выполнения: 0.0022 сек в среднем
Если сделать ORDER BY views то 0.0050 с
Переделанный запрос.
SELECT SQL_NO_CACHE nm . * , n . *
FROM 2z_news_map nm
LEFT JOIN 2z_news n ON n.id = nm.newsID
WHERE nm.categoryID =16
OR nm.categoryID =8
LIMIT 0 , 30
Время выполнения: 0.0037 сек в среднем
На 0.001 запрос с JOIN использующий индексы выполняется хуже, чем полный перебор всей таблицей с REGXP.
Если добавить ORDER BY n.postdate DESC (или views) в переделанный запрос, то выполнение вырастает до 0.3 сек. !!!
Ситуация меняется, если ставить LIMIT 0, 2000 например. Тогда у REGXP - 0.1630 сек, против 0.0784 сек. Выигрыш в два раза. Но такие объемы никому не нужны ясное дело.
Две проблемы:
1. Почему полный скан оказывается быстрее. Думаю из-за того, что мы быстро получаем необходимые 30 записей. Но непонятно это так совпало для этих категорий и какая вообще будет тенденция для универсального решения? Пока от JOIN'а не в восторге. Но возможно при других категориях он выдаст более интересные результаты и можно будет пожертвовать разницей в 0.001 с Посмотрел для категории с ID = 5, теперь REGXP проигрывает 0.0065 против 0.0019. Новости все эти не очень близко к началу.
2. Главный. Почему при JOIN'e при добавлении ORDER BY n.postdate DESC все накрывается медным тазом и начинает дико тормозить по 0.3 с?
Зачем тебе $mass, тут же в цикле
foreach ($mysql->select($query) as $row) { $tvars['vars']['test'] .= $row['text']; }
Это обычное склеивание, я ж не знаю в каком виде тебе нужен вывод
Ты же в функции showStatic не объявил
global $mysql;
Что не получается? По моему тебе нужно вывести содержимое шаблона регистрации в main.tpl и все.
$staticID - ID статической страницы.
$SQLnstatic - массив, соответствующий строке из таблицы _static
Должно работать. Возможно в файле versin плагина с списке действий не указана статика: Acts: static
$template['vars']['abc1'] = 'text';
поддердка
Это возможно. Если никто не сделает завтра посмотрю.
t3s, понял, я думал ты про какие-то хитрые оптимизации запроса.
Можно регуляркой ссылку HTML искать..
У тебя есть текстовая строка из категорий через запятую. Каким массивом? Какой первый элемент?
Не совсем понимаю как это возможно, надо проверить. То что произвольно категории могут записываться это да, а вот за порядком отмечания чекбоксов вряд ли кто-то следит...
$SYSTEM_FLAGS['news']['db.categories'] содержит тоже, что и catid, доступна только на странице новости. Не подходит.
мне нужно получить лишь те материалы, для которых категория с ид 10 является корневой
во, теперь понял.
Сейчас ты хочешь сказать, что главная категория может быть в любом месте и не обязательно на первом? Если да, то это косяк, как по мне, главная должна быть первой обязательно.
Можно просто новостную организацию улучшить. Есть категории у которых есть дочки, при этом сами они не дочки, а сами по себе, они могут быть только главными.
Например, главная ID = 3. У дочки родитель эта категория и сама она имеет ID = 10. Тогда можно сделать запрос к таблице news_map и все новости с категорией ID = 3 и будут нужными тебе, гарантированно главные. То есть не допускать ситуацию, когда категория может быть и главной и дочкой одновременно.
Если это не подходит:
1. Если главная пляшет как сейчас, то в середине, то в начале, то только использовать LIKE, иначе никак. Только условие поменять, что рядом допускается только запятая, чтобы для 10 не попадало 110.
2. Если в двиге будет поправлено и главная будет первой, то LIKE можно облегчить, указав % один раз, после категории.
Или переменная $SYSTEM_FLAGS['news']['db.categories'] доступная везде
Если ты говоришь про новостной фильтр, то переменная $SQLnews содержит весь список полей БД для конкретной новости. В том числе и поле catid.
Вывода где? В новостях? На главной? Вывода чего? ID, ссылок на категории, их названий?
Я не понял вопроса
Главное преимущество ТВИГА это то, что первый раз он работает с TPL файлом, делает из него PHP и потом работает только с PHP вариантом, в отличии от стандартного шаблонизатора, который постоянно регулярками ищет в текстовом файле переменные. Посмотреть и ужаснуться что он сгенерировал можно в папке с кешом сайта.
Компилирует он заново по моему только при модификации шаблона.
Следуя логике твоего сообщения новый форум будет либо хорошим и платным, либо плохим и бесплатным
да, поэтому надо давать возможность отключения визивига
т.е. ты предлагаешь сделать из НГ вторую джумлу? тут дело ведь не в килобайтах, а в выборе и в том как он реализован... скажем так, если провести аналог с win/nix то пользователь виндовса не имеет возможности убрать поддержку АМД, если у него интеловский проц (и наоборот) - а линуксоид при компиляции четко указывает "у меня АМД и поддержка интела мне не нужна"
о боже "при компиляции" и кто его компилирует, 1% пользователей
Напиши в офлайн плз, буду за ноутом открою
Обновил сообщение. Возможно не другой шаблон нужен.
Чего не хватает?