<?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='\
Использование в запросах виртуальной таблицы регистра накопления остатки и обороты зло.
А я наивно верю и жду, что 1С даст возможность делать такие вот примитивные запросы:
Или я один такой?
(2) ya.Avoronov, Я не жду.
Так как «нормальных» и универсальных решений этой задачи не существует.
Либо сабжевый костыльно-антиреляционный подход (материалы статьи, кстати, довольно вторичны и боянисты), либо табличку засылать (что тоже далеко не фонтан).
Оптимально было бы табличку генерить на стороне сервера БД хранимкой. Это было бы как раз нормальное решение. Но 1С на это не пойдет, т.к. это повышает стоимость кроссплатформенной поддержки.
(1) ivanov660, это где Вы такое вычитали? А если статистика обновлена, индексы дефрагментированы все равно зло? Может так стоит говорить о РБ, хоть и с натяжкой?
Чувствую, но намечается нехилый батл! 🙂
(4) DoctorRoza,
стоит пару раз увидеть конечный запрос в sql
в зависимости от потребностей быстрее может быть выборка остатков на начало и изменений на каждый день. но нужно смотреть по ситуации.
После Ильдаровича все такие публикации смотрятся как второсортный баян.
И насчёт виртуальной таблицы — согласен, зло почти всегда.
(6) Yashazz, Несколько вопросов. Ты кто такой? Ты построение запросов анализировал? Как относится к твоим бла-бла-бла о баянах?
(5) nickpugachev, если Вы работаете с крупным производством, то, конечно же, разбирали основные типовые отчеты УПП 1.3. Например, ведомости (ВедомостьТоварыНаСкладах), то они все из виртуальных таблиц ОстаткиИОбороты. И это зло? «Сомневаюсь!» (Киселев). 🙂 А если зло, то самое меньшее из! Хотя да, все по ситуации.
чето перемудрено вроде
ВЫБРАТЬ
НАЧАЛОПЕРИОДА(Товар.Период, ДЕНЬ) КАК Дата,
Товар.КоличествоКонечныйОстаток
ИЗ
РегистрНакопления.ТоварыОрганизаций.ОстаткиИОбороты(&Нач, &Кон, Регистратор, , ) КАК Товар
(9) and_sk, что именно перемудрено?
даты в отрыве от данных частные задачи
и мне кажется не требуют какогото особого подхода
решаются в порядке поступления))
(11) and_sk, да, в большинстве случаев так и есть. Но есть задачи как расчет среднесуточного остатка или оборачиваемости товара. В таких задачах надо все даты.
+(13) По задаче 4:
Всего два свойства? — Но тогда все должно быть ГОРАЗДО проще!
Все комбинации получается сразу всего одним простым запросом:
+(13) «изюминки» во второй половине задачи 3 я не увидел. Если речь идет о замене соединения на запрос с конструкцией ГДЕ (Поле1, Поле2) В (Выбрать Поле1, Поле2 Из …), то эффективность такой замены нужно тестировать на разных СУБД. Смотреть планы запрос
(7) по пунктам:
Посетитель сайта «Инфостарт».*
Как минимум маловнятный вопрос. Построение — это которое программист 1С в коде делает? Текстом, конкатенацией, или объектной моделью запроса? А может, это которое 1С делает, когда в язык запросов СУБД транслирует? Или это вообще о работе планировщика речь? Увы мне, не смог понять…
А вот Ильдарович уже и ссылку подкинул, и объяснил. Грешен я, занят был, некогда мне было своё частное мнение детально разжёвывать.
*а вообще спасибо, посмеялся
(16) Yashazz, Ильдарович свои соображения изложил внятно, мне не жалко будет на такой подход человека потратить время на ответ, чуть позже после работы. Ну а ты то тут каким боком? Сказал о зле виртуальных таблиц заезженную тему и на этом усё? Как автору статьи, потратившему все-таки хороший кусок времени на ее изложение, печально слышать какие-то темы о баянах. Посему, если нет времени, нет желания отписывать или есть прочие у тебя дискомфорты, тогда чуть полем-полем, а потом лесом и подальше от этой темы. В противном случае по существу, без выделывания. Ок? Надеюсь моя мысль услышана. Спасибо.
(12)
На всякий случай замечу, что в статье показано, как рассчитать среднедневной остаток вообще БЕЗ расчета остатков по дням.
(13) ildarovich, 1) Ваш запрос был взят для сравнительного примера. В разделе 3 статьи я получил небольшой процент прироста производительности своего запроса в сравнении с Вашим. Эти тесты я выполнил вручную в консоли запросов. На досуге найду время и проведу тесты с использованием обработки, которую я описал в разделе 5. Отпишу о результатах.
Относительно запроса, который Вы приводите как более оптимальный в этих комментариях. Меня терзают сомнения, что он более оптимален, т.к. в нем присутствует выборка из двух виртуальных таблиц регистра. И в случае, когда, дисковая система сервера баз данных оставляет желать лучшего, чтение двух наборов данных может дать дополнительную задержку. Думаю, выборки из одной жирной таблицы остатки-обороты тут достаточно, но этот момент также требует тестирования.
«Но НАДЕЖНЕЕ таблицы ОБЪЕДИНИТЬ перед соединением с датами» — тут немного смешно звучит, ведь «НАДЕЖНО» оно и в Африке надежно будь то запрос-объединение или соединение полной таблицы с выборочными данными.
«Направление оптимизации выбрано (по моему мнению) неверное» — Ваше мнение, спасибо. Я же в статье показываю что при реализации запроса с паралельным фильтрующим соединением в клиент-серверном варианте получаем значительный прирост быстродействия по сравнению с запросом с группировкой. Ключевым в этой реализации есть индексированная базовая таблица. На ее формирование уйдет время и ресурсы сервера, однако, затраты времени на формирование таблицы будут перекрыты выгодой от производительности запроса. Ресурсами сервера пренебрегаем, т.к. я рассматриваю эту тему, как вариант убыстрения выполнения запроса на больших объемах данных, а не минимизацию кода или потребления ресурсов. У Вас есть похожая статья, было бы интересно, сравнить результаты от выходы решений. Правда, мои тесты производились на числовых данных, на индексированных данных типа «дата», боюсь, будут другие результаты.
«Такое решение встречается часто, то есть новизны в предложенном решении нет.» — поделитесь ссылочкой, а то я это решение из своей практики взял, а не с Googля.
Спасибо
(15) ildarovich, «изюминки» во второй половине задачи 3 я не увидел. — задача 5 на том-же запросе. Добавил в статью. Для меня такой подход, ну не сколько изюминка, возможно кислинка, но приятная 🙂
(18) ildarovich,
. Математика Вашего расчета сходится и оптимальна. Тогда поправлю себя «Но есть задачи
как расчет среднесуточного остатка или оборачиваемости товара, в которых надо все даты.(14) ildarovich,
Всего два свойства? — Но тогда все должно быть ГОРАЗДО проще!
Да, можно и проще. Первоначально делал запрос на разные количества свойств, а потом за отустствием времени плюнул, «обрубил» его и выложил как есть.
У вас на СКЛ сработал паралелизм, необходимо отключать паралелиться запросы.
(23) logarifm, Да, это план выполнения запроса с поиском минимального значения при группировке. Этот процесс СКЛ разбил на несколько потоков. Почему необходимо отключать? Хоть это больше потребляет ресурсов в единицу времени, зато убыстряет выполнение задачи.
(19) по вопросам 1-4 взаимопонимания мы не достигли, ну да ладно, я свое мнение высказал.
По вопросу 5 очень интересно. Такая информация (об эффективности в MS SQL ПО (…) В (ВЫБРАТЬ … ИЗ)) здесь проскакивала, но без замеров и демонстрации плана запроса она не была так убедительна. Время на построение индекса в замерах учитывалось? — Проверю, буду иметь ввиду. Жаль только, что эффективность этого приема так сильно зависит от СУБД.
(25) ildarovich, нет. время, потраченное на создание индексов в тесте не учитывалось. Предполагалось, что на входе у нас уже есть индексированные таблицы .
Смотрю результат оптимизации — то же соединение, группировка да еще и помещение во временную таблицу. Прирост скорости, скорее всего, получен был за счет замены таблицы Курсов на порождающий запрос. А в запросе так и осталось соединение Дней с виртуальной таблицей остаков/оборотов.Прошу прощения, поспешил.
Порой смотрю на тексты запросов и возникает мысль — страшно далеки они от
народапрактической реализации.Почему
Показать
а не
Показать
Или потом сортировать результат теряя время полученное от всех предыдущих оптимизаций?
(28) kosmo0,
1.В практической реализации сортировка необходима не только по датам, но и по другим разрезам выборки, поэтому все-равно придется сортировать или запросом, или на этапе компоновки результата. В практической реализации пакетных запросов с большим объемом данных важна индексация в первую очередь и правильное соединение запросов.
2. Изменив порядок таблиц в выражении, Вы можете однозначно утверждать, что в таком случае выборка будет всегда отсортирована? Результат получился таковым, потому что SQL сформировал такой план выполнения запроса. У Вас есть доводы?
3. Применение таких выборок — страховка от возможных потерь данных, в сравнении со случаями, когда периоды мы получаем из регистров. Что Вы там говорили о практике?
(13) ildarovich,
Я не интересовался, как работает механизм нахождения остатков платформой. Если есть ссылка на описание, поделитесь.
Я планировал сделать сравнительные замеры своего запроса и запроса, который был предложен Вами выше в комментариях, да пока это невозможно, т.к. запросы выдают разные наборы данных. Предоставьте пожалуйста самый оптимальный с Вашей точки зрения запрос, который за любой период с отбором по складу даст выборку остатков номенклатуры на каждый день из периода. Я продолжу потом сравнительный анализ. В Вашей реализации запроса по некоторой номенклатуре не будет данных по остаткам на каждый день. Это вызвано тем, что для реализации алгоритма расчета Вы использовали периодичность «Период» таблицы «ОстаткиИОбороты». При такой реализации, если товар пришел первый раз на склад позже «НачалоПериода» — по этому товару будут отсутствовать данные по остаткам по дням от «НачалоПериода» до даты поступления этого товара.
(30) (30) информация как считаются остатки платформой внутри периода итогов есть в «белой книге». Это двухтомник «Профессиональная разработка в системе 1С:Предприятие».
Я специально проверил насчет
и ЧТОБЫ ЭТОГО НЕ БЫЛО использовал конструкцию
где используется
которая должна давать нулевые записи, даже, если остатков на начало не было. А вы проверяли или заключение умозрительное?
(31) ildarovich,
Я действую по принципу «доверяй, но проверяй».Смотрите две ситуации с таблицей «Остатки и обороты» для такого стечения данных по движениям товара в отношении к нашему периоду выборки. В одном случае на конец периода есть остаток и таблица остатков-оборотов по периодичности «Период» дает данные. В другом случае — на конец периода нет остатка, таблица не дает данные при использовании периодичности «Период». Для второго случая результирующего запроса выпадают данные, до первого поступления товара. Первая дата в такой выборке будет — дата первого оборота из таблицы оборотов. Если бы использовалась периодичность остатков и оборотов «День», тогда мы получили бы данные, да логика Вашего общего запроса тогда не работала б. Поэтому я и написал, дайте окончательный правильный запрос.
(29) Прежде всего хотелось бы адекватной реакции по сути, а не ответа в стиле -«мне адреналин с мочой в голову ударил и я стал контратаковать». (это видно по пункту 3 который добавлен до кучи и совершенно не относится к моему посту).
По пункту 1. В большинстве случаев желание получить список чисел или дат подряд означает что важно получение данных в разрезе дат. (но, опять же, это в реальной жизни).
По пункту 2. Вы можете ОДНОЗНАЧНО УТВЕРЖДАТЬ что верна Ваша точка зрения?
Я могу утверждать что описанный подзапрос был банально скопирован. Оптимизация запросов это желание привести к некому идеальному результату. Люди стремящиеся к идеалу не любят беспорядка. Результат же скопированного подзапроса это маленький бардак.
На этом откланяюсь, участвовать в говносраче не имею желания.
(33) kosmo0, 1. Вы залетели в эту тему с мыслью и заявлением
. Я опровергну эту мысль тем, что подчеркнул: перестроенная Вашим образом выборка дала результат отсортированных чисел по возрастанию лишь потому, что сервер баз данных сформировал такой план выполнения запроса. Попросту говоря, вы подобрали запрос таким образом, чтобы результат бы отсортирован. Однако повторю то, что я хотел сказать. Ваша структура запроса не дает гарантии, что на другой версии сервера баз данных будет такой-же план выполнения запроса и Вы получите отсортированную таблицу. Логично?
2. Я также не могу утверждать, что на другой версии сервера базы данных, не получится упорядоченная таблица, т.к. это требует анализа, хорошего знания работы платформы сервера.
3. Мои выводы основаны на том, что в таком запросе 1С с сочетанием таблиц не прослеживается явное создание сортировки. Если бы Вы построили эту выборку на базе «Левых» соединений, возможно я бы согласился.
4. И последнее. Не я заявлял «далеко от практики» без особых аргументов. Я говорю и анализирую. В случае моей ошибки, я поправляю себя. Вы можете заметить перечеркнутые выражениях в моих постах. Посему, г…срач, как Вы говорите, скорее всего развожу не я.
Спасибо за Ваше участие.
(14) ildarovich,
Всего два свойства? — Но тогда все должно быть ГОРАЗДО проще!
Все комбинации получается сразу всего одним простым запросом
Запрос по задаче 4 у меня был сложным и в несколько пакетов, т.к. разрабатывался как универсальный запрос на произвольное количество свойств и в последствии был «обрублен» и выложен как есть. Исправил этот недоработанный момент и изменил 4-й раздел статьи. В разделе я выложил новый запрос, который без дополнительных временных таблиц выдаст выборку «в столбик» отсортированных и пронумерованных комбинаций сочетаний свойств товара. Как Вам это? ГОРАЗДО проще или нет?
Обработку для тестирования запросов по 5-му разделу статьи прилагаю тут, т.к. она идет как приложение к статье, а не программный продукт. При запуске не стоит сразу указывать много временных таблиц для анализа и большие размеры таблиц, т.к. выполнение может быть продолжительным, особенно, на файловом варианте. Ссылка на обработку:
(35) запрос по разделу 4 я посмотрел. Про «зеркально» понял. Предыдущего варианта у меня нет, поэтому насколько удалось упрощение сказать не могу. Мог бы подумать, как упростить нумерацию в вашей схеме, но большого желания нет. Написав ту исходную статью, не увидел большого интереса к этой задаче. Хотя она взята из практики. Те, кто въехал, делают то же самое через декартово соединение таблиц свойств. Нумерацию чаще удобнее делать вне запроса. Поэтому задача довольно экзотическая и тратить на нее время жалко.
Но у меня встречный вопрос: а зачем вам свое решение в этой задаче. Ведь в исходной статье решение исчерпывающее и универсальное (на ЛЮБОЕ количество свойств). С быстродействием проблем нет. Свойства два — тогда хватит одного повтора и длина запроса будет меньше или равна длине вашего варианта (вы немного схитрили и записали в одну строку несколько полей). Если раскрыть запросы конструктором, то длина будет почти одинаковой. А в комментарии я показал ну очень простую и понятную схему для двух свойств без всякого накопления. Зачем вам топтаться на этой экзотической и уже решенной задаче? Какую новизну, какую идею вы хотели привнести в решение?
(32) смоделированная вами ситуация выглядит надуманной. В варианте (13) выпадают только строки, которые имеют нулевые начальные И конечные остатки И приход в середине интервала И который весь закрывается возвратом (приходом с минусом). Редкая ситуация. Можно было бы пренебречь. Ведь мы пренебрегаем случаями, когда приход и расход делается в один день (гардероб, детский сад). Но в принципе я не возражаю доработать запрос на отмеченный в (32) случай. Сделаю это чуть позже. Заранее могу сказать, что результаты теста будут зависеть от данных базы. Поэтому для честного соревнования нужно будет договорится о том, на каких данных будет идти тестирование. Кроме того, я знаю еще минимум три-четыре других способа интерполяции остатков. Их пока не рассматриваем?
(38) Статьи ildarovich’а предельно лаконичны, поучительны и содержательны. За что ему большой респект. Непросто писать просто о сложном.
В вашей статье, по сути, первичен и интересен только один момент (лично для меня, конечно же) — способ оптимизации производительности запросов 1С в MSSQL в некоторых шаблонных ситуациях, путем использования коррелирующего подзапроса. Но это эта информация подана значительно более громоздко, чем могла бы. Отдельная статья с таким исследованием (а если бы еще и в сравнении с другими СУБД — вообще бомба) смотрелась бы гораздо более интересно и была бы более эффективна для аудитории, по моему мнению. Намеки на заангажированность ildarovich’а, которая якобы встает стеной между вами и аудиторией, мешая ей адекватно потреблять инновационный контент — несостоятельны и вызывают улыбку.
Но мне понятно ваше негодование как автора и творца, который потратил время и силы, а в ответ получил неблагодарную публику. Да как они смеют, вообще!
(39) herfis,
Да, согласен с Вами. Товарищ ildarovich молодец.
тоже согласен, потому что привык все разжевывать. Тем более, я применил подход этот в нескольких запросах.
Публика-то разная. Кому-то надо разжевывать, а кто-то и на пальцах поймет.
— 100%, Вы мои мысли прочли! 🙂 Прямо и добавить нечего.
Но добавлю. Во всем надо сомневаться и учиться мыслить самому, а не только «как в книжке написано или кем-то сказано».
Спасибо за веселый комментарий.