|
|
14.04.2011, 13:30
|
|
Гость
Гость
|
В поле "Объект в списке" для вывода тегов каждого объекта вставил код (как написано в руководстве по модулю):
Код:".opt( $f_Tags, "<br />теги: ".listQuery("SELECT a.Tag_ID, b.Tag_Text FROM Tags_Message AS a LEFT JOIN Tags_Data AS b ON a.Tag_ID=b.Tag_ID WHERE Message_ID=$f_RowID GROUP BY a.Tag_ID", "
<a href='/tags/?tag=\$data[Tag_ID]'>\$data[Tag_Text]</a> ")."
Объектов на странице планируется 20, значит и столько же будет запросов по тегам. Это очень много. Да еще если в базе тысячи объектов и столько же будет запросов. Непонятно, зачем неткатцы пишут такие вещи в руководстве - отдельные запросы в списке по каждому объекту - глупость какая-то. Ну да ладно.
Что можно предпринять, чтобы в списке эти запросы не выполнялись?
Может как-то в системных настройках дописать основной запрос или еще как?
Пытался, но ничего не получилось, галиматья в списке.
Пытался вот так в системных настройках:
Код:$query_join = "LEFT JOIN Tags_Message AS b ON (a.Message_ID=b.Message_ID)";
$query_join .= "LEFT JOIN Tags_Data AS c ON (b.Tag_ID=c.Tag_ID AND a.Message_ID=b.Message_ID)";
$query_join .= "LEFT JOIN User AS d ON (a.User_ID=d.User_ID)";
$query_select = "b.Tag_ID, c.Tag_Text, d.Login, d.UserName";
$query_group = "b.Tag_ID";
$result_vars = "\$f_TagID, \$f_TagText, \$f_UserLogin, \$f_UserName";
Вообщем нагородил и совсем запутался.
В этом коде еще выборка по данным пользователя добавившего объект, тоже нужно по каждому объекту.
|
|
|
14.04.2011, 13:42
|
|
Гость
Гость
|
Ошибку сам ашел, надо же группировать $query_group по id объектов, так правильно:
Код:$query_group = "a.Message_ID";
Теперь все работает как надо.
|
|
|
14.04.2011, 13:59
|
|
Гость
Гость
|
Поторопился, не все работает.
У каждого объекта в списке выводится только по одному тегу, хотя у некоторых объектов их по несколько.
Где я ошибся в запросе? Не могу сообразить.
|
|
|
14.04.2011, 14:34
|
|
DiGGy
DiGGy
Зарегистрирован:
2005-04-04
Сообщений: 1546
|
Ваш вопрос:
Цитата:Где я ошибся в запросе? Не могу сообразить.
Ваш ответ:
Цитата:У каждого объекта в списке выводится только по одному тегу, хотя у некоторых объектов их по несколько.
Только по этой причине "неткетовцы" делают отдельный запрос в поле "Объект в списке".
Проблема лишних 20 запросов - это не проблема. Смотреть надо не на количество запросов, а на их качество и на то как каждый запрос влияет на общее время генерации страницы. Запросов может быть хоть тысяча хоть 10 тысяч и это не предел.
Если запрос "неткетовцев" долго работает, то создайте индексы на нужные поля в нужных таблицах.
Если не спасет, то тогда уже решайте свой вопрос на уровне записи компонента, которая изначально хранит ИД тегов - вот также по аналогии можете хранить наименование этих тегов. Реализовать такую хрень можно за 5-10 минут, ниче сложного.
Temet nosce...
|
|
|
14.04.2011, 15:09
|
|
Гость
Гость
|
Спасибо за просвещение, согласен.
Но все же, например у меня 20 объектов на странице, к примеру 5000 объектов в компоненте и 20000 тегов к ним, и к этим страницам одновременно обращается 5 пользователей ну или посещаемость за день минимум 5000 челов.
Так, как это сейчас listQuery по тегам неткатовцами реализовано в поле "Объект в списке" не завалит базу?
|
|
|
14.04.2011, 16:30
|
|
Asiat
Аниматика
Зарегистрирован:
2005-12-12
Сообщений: 576
|
Цитата:Проблема лишних 20 запросов - это не проблема. Смотреть надо не на количество запросов, а на их качество и на то как каждый запрос влияет на общее время генерации страницы
Это верно. Иногда замечал, что запрос по нескольким таблицам выполняется гораздо тяжелее, чем ежели его разбить на несколько (хотя в основном нам твердят обратное). Причем индексы все присутствовали. Тут надо научным методом "тыка" смотреть.
|
|
|
14.04.2011, 17:02
|
|
Гость
Гость
|
Убедили, буду "методом тыка" смотреть 
Оставлю все как есть, т.е. по неткатовски.
|
|
|
28.04.2011, 18:41
|
|
Гость
Гость
|
You've hit the ball out the park! Incerdilbe!
|
года. В общем, обращайтесь.