<?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='\
Интересно иногда надо
Круто. Правда, нумеровать предпочитаю с помощью СКД. Да и вообще некоторые функции СКД уже существенно облегчили жизнь, например, по нарастающим итогам.
Ильдарович, а не было мысли поиграть с объектной моделью запросов 8.3.5, попробовать на ней все композитные запросы (например, замыкания)?
(2) Yashazz,
1) СКД хорош на своем месте — для постобработки результатов запроса. Все же это черный ящик. Когда я писал запрос для отчета , столкнулся с тем, что первый вариант запроса в СКД работал невообразимо дольше, чем в консоли. Разработчик подтвердил ошибку и обещал исправить, но исправил или нет — не проверял, поскольку нашел обходной путь — другой вариант записи запроса. В СКД меня сейчас интересует возможность их каскадного соединения: когда в запросе что-то делается, затем делается постобработка в СКД и результат передается в следующую СКД для следующего этапа обработки. Вот этот путь кажется перспективным, поскольку позволяет быстро сделать вне запроса вещи, которые сложны для чисто запросной техники. Тут есть тонкое место — таблица значений вроде бы вводится в запрос по записям отдельными инсертами и это может узким местом. Но пока не выделил задачу, на которой можно было попробовать этот подход.
2) Относительно объектной модели запроса — мысль интересная. Но есть сомнения. Результатом будет программа (функция), которая строит программу (запрос). Пусть и более четко, но, кажется, еще менее наглядно. Здесь я бы подождал, пока эту технику начнут использовать в типовых. При наличии времени я бы стал пробовать придумать (несколько уже придумал) и использовать инструкции препроцессора в запросе, сохраняющие его читаемость. Поскольку у меня уже есть , которой я интенсивно пользуюсь, я бы внес в нее и препроцессинг текста запроса.
Интересное решение! =)
+
Декартово произведение. Если количество свойств заранее известно, то можно решить такую задачу проще. Разбиваем таблицу на столько виртуальных таблиц, сколько различных свойств. Далее левое соединение первой ВТ со всеми остальными ВТ. В итоге получим из таблицы вида:
цвет волос блондинка
цвет волос брюнетка
интеллект умная
интеллект глупая
размер груди большая
размер груди маленькая
таблицу вида:
цвет волос блондинка интеллект умная размер груди большая
цвет волос блондинка интеллект умная размер груди маленькая
цвет волос блондинка интеллект глупая размер груди большая
цвет волос блондинка интеллект глупая размер груди маленькая
и т.д.
Таким образом нечетная колонка — свойство, четная — значение
(5) Dach, все правильно, декартово произведение сразу дает все комбинации значений свойств.
Только в вашем примере колонка «свойство» во всех соединяемых таблицах — лишняя, так как каждое свойство будет храниться в отдельной таблице, естественно ее назвать также как свойство (зачем колонка, которая во всей таблице принимает одно и то же значение?). Так же как свойство можно назвать поля в итоговой таблице.
Но это очевидное решение не работает, когда свойства и значения заранее не определены. Тогда при вашем подходе придется анализировать состав свойств и набирать под эти свойства текст запроса. Метод и запрос получится громоздким. Я, в общем-то пробовал этот подход в задаче получения вариантов спецификаций — хотел просто с минимальными усилиями решить задачу. Но получилось очень длинно и коряво.
Описанный метод гораздо более универсален: работает с заранее неизвестным набором свойств.
(6) а если попробовать вот такой алгоритм:
Динамически управлять текстом запроса в цикле, да-да в цикле, ничего тут страшного.
0. Таблицу свойств и значений помещаем в ВТ на сервере СУБД.
1. Выбрать различные свойства, выгрузить в массив.
2. Цикл по массиву, получаем имя свойства, выбираем в ВТ все строки, с отбором по свойству. Имя ВТ назначаем как имя свойства.
3. Еще один проход по массиву в цикле, на этот раз получаем на первом шаге первую ВТ и далее, на последующих проходах лефт джойн. Используем менеджер ВТ, разумеется, для доступа к ВТ.
4. На выходе получаем требуемое декартово произведение.
(7) Dach, вполне можно так сделать — будет работать, но это самый неэффективный способ.
Если уж решили выбрать свойства в массив, то (как было предложено в (6)) в том же своем цикле без всяких временных таблиц постройте конкатенацией текст запроса, который сразу соединит все таблицы.
По сравнению с моим вариантом потом еще потребуется запросы, которые
1) пронумеруют варианты;
2) объединят значения из разных колонок в одну таблицу с тремя колонками.
Еще раз повторяю, я такой подход пробовал. Получается более громоздко.
Можете попробовать сами — посмотрим, что у вас получится.
Также при большом количестве вариантов в вашем подходе много времени уйдет на нумерацию вариантов.
В общем, считаю пока свой метод решения этой задачи самым гибким, компактным и быстрым.
«Последний запрос нужно повторить ]Log2(N)[ раз в зависимости от общего количества свойств N»
Если свойств будет 10, то сколько раз нужно «повторить последний запрос» ?
(9) Makushimo, запрос нужно будет повторить четыре раза:
1) ]10 / 2[ = 5,
2) ]5 / 2[ = 3,
3) ]3 / 2[ = 2,
4) ]2 / 2[ = 1.
прямо в тему обсуждения:
Оказалось, что если добавить к исходной таблице вероятность принятия свойствами конкретных значений, то можно посчитать вероятности сочетаний значений свойств и решать таким образом задачи расчета вероятностей сложных событий. Об этом написано в статье .
Здравствуйте, Люблю «непонимать» Ваши статьи :). Есть одни вопрос, Вы конструируете запросы конкатенацией в основном, а я тут наткнулся на «СхемаЗапросов», не пробовали ли вы ее? мне кажется, что она была бы Вам полезна.
(13) Илья, рад услышаться. К «схеме запросов» пока присматриваюсь. Обратил внимание на нее сразу как она появилась. Переписывать на нее уже сделанное не буду, а в новых задачках попробую. Даже задачка есть — — полным соединением. Обычная техника дала слишком длинный код. Как-нибудь перепишу на объектную модель.
С другой стороны, есть идея развить язык запросов, добавив туда инструкции препроцессора. Несколько уже придумал, но застопорился. Кажется, такой подход даст большую наглядность при программировании запросов. С такой точки зрения объектная модель запроса — лишний уровень абстракции, уводящий от сути задачи.
Еще одна задача, которая может быть решена данным методом: поиск чисел, формирующих нужную сумму. В публикации задача решается внешними средствами (на Java). А здесь можно сделать одним запросом.
Все это работает на весьма небольших выборках.
Если мы имеем дело со значительным количеством элементов выборки, а количество итераций («Цепь1, Цепь2…и т.д.) достаточно велико, то легко «ложится» любой мощный сервер.
В моем случае проблемы возникали уже на третей итерации. Не помогла даже расстановка индексов на поля, которые участвуют в соединении таблиц (у вас, кстати, почему то это не используется).
На маленьких выборках — работает прекрасно ….