<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Многие так яростно ратуют за указание параметров во всех виртуальных таблицах, забывая что в конечном итоге это будет транслировано в sql в те же join и where.
Что по вашему происходит когда выполняется выборка из регистра с указанным отбором-запросом?
СУБД находит строку в таблице, считывает обозначенные в условии поля и начинает сравнивать их со всеми полями из таблицы подзапроса-условия. Ровно тот же самый join.
Можно еще поспорить на тему отсутствия индексов во временной таблице, но тут только профайлер рассудит. Может у вас там всего 1 запись в документе и индекс будет тормозить, или записей там тыщи и отсутвтвие индекса роняет вам сервер.
А вот лишнее!! соединение точно тормозит запрос (одно в параметрах, второе после отбора из вирт таблицы)
И да. 1С даёт нам три инструмента отбора данных при выполнении запроса. Это параметры виртуальных таблиц, ГДЕ и ИМЕЮЩИЕ. А в sql всего два.
Не надо бездумно повторять за методистами 1С, они дают практику общих случаев, чтобы грубых ошибок избегали новички. Преподносить это как святую истину в любой ситуации не верно.
(1)
Объясните подробней,пожалуйста…
От условия ГДЕ или амперсанда & — не избавится ни при каком раскладе….В первом варианте с помощью ГДЕ — задаются параметры ссылки на данный документ, а во втором — с помощью & Параметром выступает вся временная таблица.
…а что за оператор ИМЕЮЩИЕ в 1с?
…каких два в sql ?
Если на сервере будет стоять одна конфа, в которой перебор изначальных данных ограничен списком самих данных, н-р, 5 товаров, а 150тысяч из базы; и другая конфа — в которой перебор данных идет по всем 150тысяч товаров из базы — то какая база быстрее всего «упадет» на сервере????
Причем в условиях и параметрах запросов обоих баз будет все одинаково (те же условия ГДЕ или амперсанд &) и соединения таблиц одинаковые — левые, разница только в одном — только в одной базе на огромной по весу таблице регистров будет стоять доп.фильтр из той же временной таблицы, а на второй — не поставлен такой фильтр.
(2) Про 1С оператор ИМЕЮЩИЕ и его sql аналог having вам расскажет гугл
Про 1С оператор ГДЕ и его sql аналог where вы думаете, вы знаете.
Других операторов отбора данных в sql нет. А в 1С , внезапно, есть параметры виртуальных таблиц. Которых в sql нет. Но, как мы знаем, сам 1С запросов к бд выполнять не умеет. Вместо этого запрос транслируется в запрос sql и выполняется субд. Значит 1С операторы параметров виртуальных таблиц будут транслированы в те же операторы sql
Понимание этой базовой вещи приводит нас к тому что запрос соединяющий виртуальную таблицу с временной таблицей документа при помощи внутреннего соединения выполняется в sql ровно так же как запрос к виртуальной таблице с параметром являющимся выборкой временной.
Запрос1
ВЫБРАТЬ Продажи.* ИЗ ПродажиОборот(,,Номенклаура = (ВЫБРАТЬ вт.Номенклатура ИЗ вт КАК вт)) как Продажи
Запрос2
ВЫБРАТЬ Продажи.* ИЗ ПродажиОборот ВНУТРЕННЕЕ СОЕДИНЕНИЕ вт ПО ПродажиОборот.Номенклатура = втНоменклатура КАК Продажи
Это одинаковые для субд запросы. Причем во втором варианте СУБД автоматически индексирует «вт» по полям соединения, а в первом мы ОБЯЗАНЫ не забыть это делать сами (Хрусталёва забыла)
Поймите, что перебор всех 150тыс товаров произойдет в каждом из этих случаев. И делать двойной запрос к данным, сначала в параметрах, а потом еще и в соединении , это торможение запроса. Незначительное, но торможение. Им можно и пренебречь. Выберет запрос сначала 5 данных из 150тыс, потом еще раз 5 из 5ти. Никто не заметит.
Но громко в тексте утверждать, что соединения всегда хуже чем запросы в параметрах вирт таблиц, это заблуждение, хоть и не ведущее к плачевным последствиям. Максимум замедление работы вдвое. Не надо такое безапелляционно утверждать на публике
(4) «Уважаемый педагог Е.Хрусталева предлагает сократить данные трудозатраты — и еще на этапе формирования второго запроса, в параметры каждой энергоемкой таблицы регистра — накладывает фильтр, который и есть, собственно, созданная ранее ВТ. »
Фильтра не существует в субд. Он есть только в 1С , как вымышленная сущность призванная избавить программистов 1С от грубых ошибок. Чтобы отфильтровать по желанию 1С записи из БД, реальный сервер sql выполнит ровно те же действия что и при соединении таблиц. Он переберёт все 150тыс записей регистра и сравнит их с 5ю записями документа. Ровно то же самое сделает он при простом соединении.
«причем она делает очень верно — сокращая таблицы регистров перед их Соединением с ВТ»
В том то и дело, что сокращения не происходит. Она дважды выполняет склеивание таблиц, тем самым увеличивая время запроса. В вырожденном случае когда в регистре ровно столько же записей сколько в документе (например сделали док поступления на 10 строк, потом делаем документ полной продажи на те же 10строк) , запрос Хрусталёвой будет выполнятся ровно вдвое ДОЛЬШЕ чем простое соединение виртуальной и временной таблиц, безо всяких предварительных условий
И еще раз.
Не бывает фильтрации таблиц регистра. Есть только join и where. Так работает субд, согласны с этим методисты 1С или нет, неважно.
Кстати фирма 1С при сдаче официального экзамена «Эксперт по технологическим вопросам» просит опиратся на логику именно sql запросов, а не методически верных книг «1С для чайников»
(6)
….если Вы так уверены в этом, значит Вы умеете пользоваться этими всеми серверными sql-штучками, типа ExpressProfiler22wAddinSigned и др., и тем более есть возможность на реальном серваке протестить оба варианта запроса и выложить результаты производительности….
п.с. иначе, просто все преподы….они что,сознательно изначально учат в принципе неверному подходу?????????? Это слишком серьезно….я просто заметила, что в книге — дан слишком непростой метод построения ВТ, можно намного проще, наглядней и доходчивей создавать ВТ….А Вы утверждаете, что все намного еще глубже не правильно…
(7)
Уверен. Есть возможность. Более того, тестировал лично месяц назад. Была задача по оптимизации запроса. Он выполнялся 12 секунд. Немного вроде, но очень уж часто пользователи к нему обращались.
Нашел ошибку предыдущего программиста — отсутствие индекса во временной таблице. Затем эта временная таблица идет как параметр-выборка к виртуальной и еще как левое соединение к этой же виртуальной. Примерно как вы делаете в исходной теме.
Поставил индекс к таблице — время запроса уменьшилось до 0.45с
Убрал вообще параметр из виртуальной таблицы — время запроса 0.3с
Все замеры выполнял минимум трижды, совпадали до сотых долей секунды.
(8)
Поставил индекс к таблице — время запроса уменьшилось до 0.45с
Хорошо, что не Вы не против самой фильтрации огромных регистров на входе в запрос, только лишь за то,чтобы ставить индексы….
но фильтр ВТ уже идет по ссылке…чем это не индекс????….Предложите формулу фильтрации по индексу…
Итак, нашла я решения индексации полей Запросов — это функция «ИНДЕКСИРОВАТЬ ПО», но на том же сайте сказано, что если таблица запроса маленькая по объему и если далее соединение этой таблицы идет по ссылке (а именно так у меня), то индексирование — это лишнее!!! В этом случае индексирование ухудшит производительность!!!
п.с.чтобы быстро перейти на тот сайт — вот цитата с него:» На бескрайних просторах инета неоднократно встечался со статьей, описывающей причины неоптимальной работы запросов. В данной статье присутствует такая фраза: «В качестве индексных полей следует указать все поля, которые используются в условии соединения«. Воспользовавшись данной рекомендацией и получил неожиданный результат: итоговое время выполнения пакета запросов после добавления индексов увеличилось. Где-то в 1,5 раза. Естественно, индексы пихал не во все подряд временные таблицы, а лишь в те, которые заведомо будут весьма большими. Хотелось бы узнать у гуру оптимизации — в каких случая всё-таки следует производить индексацию конкретного поля, и для каких полей индексация будет заведома бессысленна? В общих чертах механизм работы индексов представляю, однако тыканье носом в теорию поощряется.»
А почему бы не показать еще третий вариант: запрос к табличной части документа и к остаткам в одном пакетном запросе? Мне кажется, это самый простой и наглядный вариант.
(11)
да,это самый простой вариант:
Показать
Объясните, пожалуйста, а в чем такая принципиальная разница в данном конкретном случае между временной таблицей и например вложенным запросом? Специально попробовал создать в консоли запрос, похожий на этот ( с созданием временной таблицы из табличной части документа и соединением ее с виртуальной таблицей), и на сопоставление похожий запрос, только вместо временной таблицы — вложенный запрос с той же самой табличной частью. И второй запрос даже быстрее отработал. В учебнике Хрусталевой смысл, насколько понимаю, в том, что таблица кочует из запроса в запрос, а тут же, так как используется всего лишь единожды, можно и вложенный запрос использовать.
(13)
именно,правильно,в этом и смысл,т.к. далее этот препод использует сохраненную в МенеджереВременныхТаблиц — созданную ее Виртуальную таблицу для определения остатков, причем сразу делает заявление, что док нужно провести(!!!), чтобы увидеть эти остатки — так никто не делает по объяснимым причинам,может Вы объясните эти причины?
п.с. но мысль мне нравится:»таблица кочует из запроса в запрос», только использование этого метода кратко и пока не знаю как его применить…
(14)
В приведенном в учебнике примере бессмысленно, а на практике может, к примеру, понадобится обработка результата первого запроса до создания второго. А в том же втором понадобится временная таблица из первого, вот и вырисовывается какой-то смысл:)
(15)
да, но любой пример из практики — был бы кстати
п.с. например,я точно знаю как использовать свой второй пример из статьи….причем это будет очень востребованно, т.к. до сих пор ВСЕ менеджеры перебирают прайсы ручками….
(13)
Поправьте, если я не прав:
Если рассматривать клиент-серверный вариант, то вложенный запрос выполняется каждый раз если требуется получить данные верхние данные, а временная таблица выбирается один раз — помещается в tempdb и обращение к ней осуществляется по мере необходимости, т.е. база уже не дергается.
Если вложенный запрос выбирает небольшое количество данных, то разница в быстродействии может быть и не заметна, а вот если это достаточное количество данных, то получение его каждый раз может добавить хлопот. А так один раз получили и пользуемся.
Очень наглядно это видно если посмотреть профайлером на выполнение запроса с вложенным запросом и с временной таблицей.
(17)
так хочется научится пользоваться этим инструментом профайлером, но только один взгляд все что там нужно дополнительно установить и запустить — пугает…
п.с.Было бы очень здорово, если Вы попробуете объяснить «на пальцах» как правильно использовать программки для просмотра оптимизации запросов.Спасибо.
(18) Увы уже очень давно не занимался оптимизацией, просто стараюсь поддерживать свои знания в этой области.
А из существующих основ для клиент-серверных вариантов только с MS SQL довелось видеть адекватные инструменты, с остальными только слышал, что что-то есть, но ни разу не пользовался.
А с профайлером на MS SQL — там главное правильно фильтр настроить, сейчас даже вроде есть более адаптивное описание как его настроить для работы в связке с 1С. Т.к. давно не занимался, то и ссылок увы не сохранилось…. 🙁
(10) sql для маленьких таблиц всегда игнорирует индексы. По моим исследованиям, индексы использовались после 5к строк — каким образом sql выбирает это количество, мне непонятно.
Автор не мог бы исправить слово «амперсант» на «амперсанд»? Глаз режет. И «пишит» на «пишет». ; (
(21)Спасибо, ЗоркийГлаз, но пока не могу исправить….так сразу же дадут медаль за лучшие познания русского языка, а слово «амперсанд» совсем не из Руси пошло….И в слово писАть: вставлять первую букву алфавита или последнюю — не имеет никакого значения, т.к. мы душу в письме изливаем в любом случае!
(6) Это просто пять с плюсом! Распечатаю этот комментарий и повешу в своем отделе на самом видном месте )))