WebAsyst - "красивые запросы" или что с этим всем делать

Slaviq

Создатель
Регистрация
19 Сен 2007
Сообщения
37
Реакции
1
Сегодня в ночь решил же ж посмотреть почему при нажатии на кнопочку Расширеного поиска ДебагТайм составляет 16 - 45 секунд.
Уточню в базе товаров >35к, категорий >5к

Включил логирование запросов мускула, на страничке из генераторов форм ничего не оставил ....
В результате после запуска по линку поиска получил log - фал весом 1.6 Мега!!!

Из этого файла 95% заняли запросы по типу по каждой категории (подкатегории) получить вложенную категорию, подкатегорию в массив и получить параметры для выбора, количество товаров ... Это делается по каждой категории!!! а потом выбираются по каждой полученной категории подкатегории!!! Карочи брэд ...

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

Сегодня буду сидеть разбираться ... думаю все это переписать нафик. Благо за плечами знаний предостаточно, было б время.

Товарищи, если кто уже занимался разбором полетов, давайте сработаемся, и родим народу нормальный вариант поисковой машины. Кто что может ценного рассказать ... милости прошу в этот топик, личку, аську, жталк ...
Сегодня начинаю расколупывателно поступательные движения.
 
Смысла в этом нету так как возиться с таким мусором который понаписали в WebAsyst это тратить лишнее время! Лучше и проще будет написать свой двиг с нуля!
 
Смысла в этом нету так как возиться с таким мусором который понаписали в WebAsyst это тратить лишнее время! Лучше и проще будет написать свой двиг с нуля!

Думаю что с подобными прибамбасами это будет долше :)
Как говорили наши дедушки и бабушки- "мы не ищем легких путей"
Уже просто потрачено время на организацию магазина на мега пупер движке. Так что пути назад особенно нету.

Тем более если сделать по человечески то мож хоть в следующих версиях разработчики будут более ответственными
 
да разработчик по большому счету клал на все, у него покупают вебасист и нормально, поверь код править не станут и корявых запросов меньше не станет, потому как там, судя по всему, работает над кодом куча людей, которые всю работу над проектом ведут несогласованно, то есть такое ощущение, что нет некоего координатора и клепают "куски" шопа разные люди, которые не в курсе что делают остальные участники.
Тому подтверждение те же неоднократно повторяющиеся запросы и тому подобный бред.
Исправлять это никто не станет, опять-таки, взять тот же самый пресловутый Shop-script, который фактически является предшественником вебасиста, так в нем такого же гамна не меньше, в чем может убедиться любой желающий, благо там даже не зашифровано нихрена

к тому же, все твои потуги в плане убрки мусорных запросов сведутся либо к застопориванию на одной версии скрипта или снесутся после установки очередного мегаобновления до некой 2.8.X
 
Пока планирую застопорится на "некой 2.8.X", в дальнейшем буду думать :)
Если такие мегаобновления как у них были, то это все можно ставить в ручную используя сравнительный анализ

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


p.s. не нужно отвечать на мой пост, загляни в личку, пообщаемся, а потом хоть самолет из WA стройте ))
 
в принципе так и хочу
... правка того что есть это "Сизифов труд" ...
так сложилось что уже назад пути нету

потому и собираюсь сделать и выложить тут решение для таких же людей, которые повелись на красивую обертку и простоту настройки, а теперь на них жалуются хостеры или на людей жалуются клиенты с претензиями - тормозит поиск

переписывать уже нет времени - нужно работать
переходить на новый двиг можно - но нет столько времени: дизайн, перенос каталога, разные доработки ....

так что предлагаю выкладывать конкретные предложения по существу
 
Вобщем много чего комментировал
страница теперь генериццо 0.3-1 сек в зависимости от времени суток :)
1. что сделал основного, так это NESTED SET:
PHP:
<?
$db_host     = "127.0.0.1";
$db_user     = "root";
$db_password = "";
$db_name     = 'mybase';
$table = 'sc_categories';
$number = 1;
make_nested(0);
/*function make_nested($parent_id = 0) {
    global $db, $table, $number;
    $c = $db->selectCell("SELECT COUNT(*) from ".$table." \
    where parent=".$parent_id."");
    for($i=0; $i<$c; $i++) {
        $newrow = $db->selectRow("SELECT * FROM ".$table." \
        where parent=".$parent_id." order by name_ru, categoryID \
        LIMIT $i, 1");
        $db->query("UPDATE `".$table."` SET lft=".$number." \
        WHERE categoryID=".$newrow['categoryID']."");
        $number++;
        make_nested($newrow['id']);
        $db->query("UPDATE `".$table."` SET rght=".$number." \
        WHERE categoryID=".$newrow['categoryID']."");
        $number++;
    }
}*/
function SQL($query) {
   global $db_host, $db_user, $db_password, $db_name, $dbh;
   if (! $dbh) {
      $dbh = mysql_connect($db_host, $db_user, $db_password);
      mysql_select_db($db_name);
   }
   mysql_query ("SET NAMES `cp1251`");   
   $sth = mysql_query($query); #mysql_query $db_name
   if (mysql_errno()>0) {
		echo(mysql_errno()." : ".mysql_error()."<BR>\r\n $query<br>");
		die("Error in sql");
		exit;
   }
   return $sth;
}
function make_nested($parent_id = 0) {
    global $table, $number;
    if ($parent_id == 0)
	{ $where =" where parent is null";} 
	else {$where =" where parent=".$parent_id;}
    $c = SQL("SELECT * from ".$table." ".$where);
	$i=0;
    while ($newrow = mysql_fetch_array($c)) {
        SQL("UPDATE `".$table."` SET lft=".$number." WHERE categoryID=".$newrow['categoryID']."");
        $number++;
        make_nested($newrow['categoryID']);
        SQL("UPDATE `".$table."` SET rght=".$number." WHERE categoryID=".$newrow['categoryID']."");
        $number++;
    }
}
?>
2.файлы category_functions.php и product_functions.php соответственно что нашел связанное с работой цикла для получени категорий и подкатегорий переписал на лаконичный (пипец умники, как такое можно писать?!)
получилось что то вроде этого:
PHP:
    $q = db_query("select lft, rght from SC_categories sc where categoryId = ".$categoryID);
	while( $row=db_fetch_row($q) ){
		$sclft = $row["lft"];
		$scrght = $row["rght"];
	}    
    $sql_category_part = " sc.lft >= ".$sclft." and sc.rght <= ".$scrght;
3. дальше делал апдейт
PHP:
update `SC_product_options_values` s
set `variantID` = (select variantId 
       from   `SC_products_opt_val_variants` c
      where s.optionID = c.optionID
          and c.option_value_ru = replaces.option_value_ru)
это имеется в виду для всех характеристик прописываем ИДшники!!!
ЧТОБЫ НЕ ДЕЛАТЬ ЛЕФТ ДЖОИНЫ!
4. в _prepareSearchExtraParameters($template){
переписал все на:
PHP:
function _prepareSearchExtraParameters($template){
	$sqls_joins = array();
	$sqls_options = array();
	$categoryID = $template['categoryID'];
	$sqls_params = array();
	$cnt = 0;
	$_count = 0;
    $sqls_options[] = '
			    1=1
			';
	foreach( $template as $key => $item ){
		if(!isset($item['optionID']))continue;
		if($item['value'] === '')continue;
		if($key === 'categoryID' )continue;
		// get value to search
		$res = schOptionIsSetToSearch( $categoryID, $item['optionID'] );
		if($res['set_arbitrarily'] && $item['value'] === '0')continue;
	    $sqls_joins[] = '
			JOIN ?#PRODUCT_OPTIONS_VALUES_TABLE PrdOptVal'.$cnt.'
			  ON p.productID = PrdOptVal'.$cnt.'.productID 
               AND PrdOptVal'.$cnt.'.optionID='.intval($item['optionID']).' 
			   AND PrdOptVal'.$cnt.'.variantID='.intval($item['value']).' 				  
			  ';	
		$cnt++;
	}
	return array('where' => $sqls_options, 'join' => $sqls_joins, 'params'=>$sqls_params);
}
вместо всех благоглупостей что там написаны
кому нужно искать по названию ... обыгрывайте сами :) мне не нужно.
Вобщем если Вы не поняли и половины из того что здесь написано ... не пытайтесь ничего делать ... только поломаете все к такой то бабушке
если вы поняли больше половины ... то дописать под свои нужды не сотавит труда :)
надеюсь кому то пригодится такое решение. Успехов!
 
PHP:
update `SC_product_options_values` s
set `variantID` = (select variantId 
       from   `SC_products_opt_val_variants` c
      where s.optionID = c.optionID
          and c.option_value_ru = replaces.option_value_ru)
это имеется в виду для всех характеристик прописываем ИДшники!!!
ЧТОБЫ НЕ ДЕЛАТЬ ЛЕФТ ДЖОИНЫ!
[/QUOTE]
Опечатка вместо replaces.option_value_ru нужно s.option_value_ru
PHP:
update `SC_product_options_values` s
set `variantID` = (select variantId 
       from   `SC_products_opt_val_variants` c
      where s.optionID = c.optionID
          and c.option_value_ru = s.option_value_ru)
К сожалению работает только для одного языка,
Хотя если добавить variantID Для каждого языка, может существенно помочь
вообще мультиязычность реализовывать добавлением полей в таблицу достаточно удобное для программистов, но очень спорное решение, но я не сильно смотрел другие магазиный. но мне поддержка шаблонов и конфигуратор пока попалась только здесь
 
многоязычность в предлженном варианте работает!
SC_product_options_values просто нужно проинициализировать ИДшниками
конкретных характеристик
в advanset_search выводятся option_value_ru, option_value_en и так далее в зависимости от выбранного языка, но они завязаны !на 1н ИДшник! который записан уже (апдейтом выше) в SC_product_options_values
 
Назад
Сверху