<?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='\
(0)
А разве это не так? Чем можете обосновать? Этот отчет только это утверждение и подтвердил.
(1) Конечно, не так.
Отчет «Обороты счета» является примером сложной перекрестной таблицы.
Реализовать такую построителем невозможно. Остается ручной кодинг.
Сила СКД — в составлении перекрестных таблиц
В теме предлагается читателю сравнить представленный отчет и типовой в БП 1.6 по быстродействию и самостоятельно сделать вывод : что быстрее ?
Автору респект. Самостоятельно я, будучи семерочником, ни в жисть бы не догадался, что обороты счета в восьмерке являются сложными и перекрестными. 🙁
Ну вот и все.
Ты теперь сам подвязался формировать «Обороты счета», потому как научить настраивать этот отчет пользователя намного сложней, чем писать ручной код как в отчете 1.6
🙂
быстродействие СКД зависит в большей степени в автоматически налагаемых параметрах на виртуальные таблицы и отбрасыванию ненужных связей и полей… Так что грамотно составленный запрос не будет медленнее СКД.
(4) Нет, неверно. Демонстрационный отчет — не для бухгалтера.
Отчет для ветеранов , которые настаивают , что СКД -«бантик».
В теме я почтительно пытался их переубедить .
Убежден , что после такого примера они «дружною толпою» перебегут на сторону энтузиастов СКД.
(5) Неверно.
Перекрестную таблицу ты «грамотно» составленным запросом в 1с не создашь.
Тебе придется «вручную» обрабатывать выборки запроса и в цикле выводить области табличного документа. Посмотри код типового отчета «Обороты Счета» в БП 1.6 или УПП .
Проблема перекрестных таблиц ( то бишь таблиц с динамическими колонками) в СУБД обсуждалась где-то в середине 90-х годов. Разные Субд по-разному решили эту проблему.
СКД конечно рулит — не но панацея.
Недавно у меня не получилось выделить (цветом, шрифтом, не важно) итоги по группировкам (строки/колонки — только итоги) в сложной перекрестной таблице. Потратил несколько часов, но так и не допер 🙁
(3) Как прожженный «семерочник» оцени код типового отчета в 77.
Поделись впечатлениями .
А проверял на SQL или файловом варианте?
(8) В конфигураторе — СКД — закладка «Макеты» — Добавить Макет ресурсов.
В появившемся окне
Группировка1 это строки
Группировка2 это колонки.
В перекрестии этих строк и колонок можно создать область макета для форматирования соответствующих ресурсов.
Например , чтобы как- то выделить последнюю итоговую строку отчета — нужно
в группировке 1(строки) поставить «Заголовок» — в Группировке 2(Колонки) поставить «Общий итог подвал». Могу соврать , но примерно так.
(10) Конечно. И на файловом и SQL-вариантах представленный отчет выиграл у типового от 2 до 4 раз. Только нужно не забыть в настройках отчета снять (в теме выделено красным) галочки (группировки по корр.субконто).
(0) Круть, а что с чем сравнивать?
Я понимаю, что наверное туплю, но всё же — какие обработки скачать? Что сравнить?
Может я просто запутался в этих трех ссылках?
(11) Эх, если бы было так легко…
Итоговые группировки строк — так получилось без проблем. А вот группировки строк и группировки колонок вместе (пересечение) — нет.
И строки и колонки строятся иерархически.
(13)
1. Запусти типовую БП 1.6.
2. Запусти типовой отчет для 62 счета , который называется «Обороты Счета».
Засеки время.
3. Запусти текущий отчет (ОборотыСчетаБП1_6.erf).
4. Убери галочки в настройках как показано на третьем сверху рисунке темы.
5. Установи 62 счет за тот же период.
6. Кнопка Сформировать
Засеки время и сравни с п.2
(15)
2. 8 с.
6. 4 с.
БП 1.6.25.5 файловый, настройки как в публикации.
За квартал:
-типовой 43
-авторский 8, быстрее в 5,4 раза.
За полугодие:
-типовой 151
-авторский 20, быстрее в 7,6 раза.
Супер.
Автор, надо в Управленческой ведомости заменить Обороты счета на новый вариант. Обязательно.
(18) Та тема закрыта. Бессмысленно сейчас что — то всерьез делать для БП 1.6.
Значит надо менять Управленческую ведомость — для БП 2 🙂
(20) Э..ээ.. эх.
Круто. КрАсава. Плюс и в мемориз 🙂
(19)
Да и на 2.0 под 8.1 — тоже бессмысленно 😉
8.2 давно уж на дворе
(23) Пожалуй.
(24) вот если бы мы увидели анализ, за счет чего типовой отчет 1.6 проигрывает СКД из 2.0 статья была бы куда полезней, а так похоже на пустую декларацию не очень оптимального кода в 1.6
Ну быстрее отчет работает написанный на СКД и что из этого следует?
(25) Постараюсь.
Итак , у вас есть регистр
Измерение1,Измерение2, Ресурс.
Вам нужно получить отчет «Перекрестная таблица» :
В строках Измерение1 ,В столбцах Измерение2 , в «перекрестье» Ресурс.
Если Измерение1 — Номенклатура , Измерение2 — Склады , Ресурс — Остаток.
То получить нужно :
———- Склад1 — Склад2 —-Склад 3
Стол
Стул
Шкаф
ИТОГО
Главной отличительной особенностью такой перекрестной таблицы является неопределенное заранее количество столбцов (динамические столбцы).
Как вы это будете делать в 8-ке ? Без построителя , и без СКД ?
Созданием такой перекрестной таблицы занимался каждый в своей жизни.
И выкручивался как мог — «вручную» . Выкрутились и разработчики «типовой» БП .
Так вот . Такую часто повторяющуюся задачу можно реализовать на уровне платформы.
(что , конечно, значительно эффективнее).
Первой попыткой в 8.0 было создание ПостроителяОтчетов. Но он позволял строить лишь простые перекрестные таблицы (Обороты счета на нём не построишь) .
Потом в 8.1 в 2007 г. появидось СКД , позволяющее на уровне платформы решать задачи построения более сложных перекрестных таблиц гораздо более эффективно чем пользовательский кодинг. Что и было продемонстрировано в текущей теме.
Правда другие СУбд , решили эту задачу на уровне платформы значительно раньше.
(15) Я не вредный, просто любопытный. Посмотрел в отчете из 6 не работают расшифровки. Вырезал расшифровки из 2. Результат:
2. 12,249 сек
6. 10,42 сек
Не такая уж большая разница получилась 🙂
(27) Всегда считал , что верна только первая часть пословицы «любопытство не порок..».
1. Ты посчитал что расшифровки можно выбросить из п .2. ?
Мы ими можем пренебречь , они не нужны в отчете ?
2. Возьми больший период (чтобы в типовом он выпонялся 2-3 мин.) .
Тогда какое соотношение ?
(15)
Игорь.
В сообщении (15), думаю, имеет смысл добавить между пунктами #2 и #3 еще один пункт — «перезагрузить систему». Или я ошибаюсь?
Спасибо за пример хорошо сделанного отчёта! Ещё можно ускорить его вынесением выполнения кода на сервер 1С:Предприятие —
(0) Режет слух в статье использование термина «раскручивать» вместо «разворачивать». Или это я неправильный?
(26) Не понял, в чем сложность построения такого отчета без СКД и Построителя?
(29) Нет , ненужно. Перезагрузка системы , конечно, ничего не даст.
(30) Конечно. Но отчет демонстрационный, код в нём минимален, директивы для компилятора убраны.
(27) Алексей . отправь мне «гостинец» — оформленный как внешний отчет «обороты счета» из типовой. С твоими исправлениями.
Ты не подумай — я тебе верю. Просто проверю.
(31) 1. Согласен. Режет.
2. Простой пример перекрестной таблицы реализовать несложно. Да и в (26) речь не о сложности . А о том, что задачу построения перекрестной таблицы лучше эффективнее решать на уровне платформы. То есть при помощи СКД.
(33) Т.е. все-таки речь идет не о сложности (трудоемкости) создания отчета типа «перекрестная таблица» разными способами, а именно об эффективности (времени) выполнения отчета? Тогда вопрос из (25), как мне кажется, остался без ответа. За счет чего отчет на СКД более эффективный? Из-за того, что отчет, созданный «ручным кодингом» недооптимизирован? Или СКД действительно более эффективна в своей внутренней реализации? Мне это действительно интересно!
(32) по ответу на (29).
Даст объективную оценку быстродействия сравниваемых алгоритмов, а не оценку эффективности кэширования системы.
(32) Сделал замер за 4 года. Результаты:
2. 45,173 сек
6. 39,845 сек
Над оптимизацией вывода результатов можно еще поработать. Сбить 2-3 секунды реально. Т.к. ~70% времени выполняются запросы, можно покопать ещё там.
Про расшифровки. Я не утверждаю, что расшифровки не нужны. Просто в типовой конфигурации на их формирование уходит значительная часть времени — почти половина времени формирования отчета. Я за честное соревнование.
Хотя я надеялся, что расшифровки появятся в варианте отчета с СКД.
(35) Подробнее.
При старте 1с Предприятие 8.1 метаданные не грузятся.
Подгрузка необходимых метаданных( а не данных !) происходит по мере обращения к ним.
Поэтому если запустить 1с Предприятие 8 и последовательно два раза запустить один и тот же отчет , то можно убедиться , что при втором запуске время исполнения отчета существенно меньше. После первого обращения метаданные уже в кэше.
Теперь вопрос : а третий запуск отчета будет быстрее чем второй ? Другими словами ,
используются при третьем запуске данные( а не метаданные!) кэша 1сПредприятия, которые остались в нем после второго запуска ?
1. Если в отчете используется запрос , для извлечения данных, то третий запуск будет не быстрее. Опыт показывает , что время 2,3, 4, 5 , запуска с небольшой погрешностью одинаково.
2. Если в отчете используется объектная техника доступа к данным ( Получаем объект и обращаемся к его реквизитам через точку) — то всё может быть. Не пробовал.
Правда , такое обращение к к данным в отчете — экзотика.
(34)
Строго говоря , утверждать что-либо можно только из опыта.
Берем Регистр со структурой в (26) и большим объемом данных. «Ручным» способом (Без построителя и СКД) рисуем отчет из (26) . Затем то же рисуем в СКД и в Построителе.
Сравниваем.
Затем то же проделываем с отчетом «Обороты счета». Сравниваем.
Мой прогноз : СКД победит и в первом и во втором случае.
Предполагаю , что :
(36) Ок. Посмотрю.
… хотелось бы ещЁ подсчитать стоимость …
штатный отчЁт — уже ничего не стоит …
просто отчЁт — сделает кто как сможе и будет работать на … 0…20 % медленне … и то не факт … вопрос а судьи кто ? и кто ЧТО знает КАК реализовать …
отчЁт на СКД — ??? … крАсивая фишка … не вижу никакго эффекта ни от её изучения … ни от её использования … опытным — это мало помогает … а для новых — забивает голову «иными» костылями …
… вотЕСТЬмнение …
п.с. постоянная потребность в «новых» отчётах — говорит об неУстоявшейся системе и правил Учёта и Управления … так что … ? … вот …
п.с.2. ВСЁ что меньше 12% — это проценты туда-суда-Нефакт … увеличение на 50 % — есть вопрос задуматься … вот если производительность вырастае в разы !!! — тогда есть смысл «смотреть» и изучать … а так … вроде все заняты делом а КПД — смешное … зато пантов-то … пантов-то … вотТАКОЕоскорбительноеМнение …
…
(40).
п.с. постоянная потребность в «новых» отчётах — говорит об неУстоявшейся системе и правил Учёта и Управления … так что … ? … вот …
Я считаю, что ты неправ, Шёпот. Требования «новых» отчетов — прямое следствие роста и развития бизнеса. Если в компании пользуются только отчетами, созданными три года назад — это свидетельствует о том, что с тех пор компания не далеко продвинулась. Это конечно относится не ко всем инструментам. Некоторые не устаревают очень долго, ими можно пользоваться десятилетиями :).
Бизнес — как живой организм, так же растет, изменяется и когда-нибудь умирает. Если у бизнеса не возникает новых задач, значит он стоит на месте.
(40)
просто отчЁт — сделает кто как сможе и будет работать на … 0…20 % медленне … и то не факт … вопрос а судьи кто ? и кто ЧТО знает КАК реализовать …
отчЁт на СКД — ??? … крАсивая фишка … не вижу никакго эффекта ни от её изучения … ни от её использования … опытным — это мало помогает … а для новых — забивает голову «иными» костылями …
Представленный отчет является демонстрационным. Как его использовать решает читатель.
Так об этом и толкую.
Выигрыш от использования СКД для больших, сложных перекрестных таблиц : В РАЗЫ .
Ответ Alexk-Is готовится.
(41) … что я не помню чтоБЫ в Бухгалтерии — менялись отчёты … ??? … в принципе СОгласен … НО!… отчЁт в месяц — возможно … ))) но ради 12 отчЁтов в год мудрить с СКД … ? … можете назвать свою цифру «новых отчЁтов» — динамических компаний … ? …
(42) … в разы … хм … ещЁ один вопрос а зачем … ? важна не только «сама»производительность отчЁта но и количество его вызовов … например, проведение и перепроведение ВАЖНЕЕ чем раз в день вызвать несколько отчЁтов ( даже пусть в пиковые, отчётные периоды вызывается несколько раз … и что… ? … отчет готовится за минуту или за 20 сек — не отчёты ЕСТЬ лимитирующая стадия работы …)
… хотя в целом производительность в разы — СОгласен … если Alexk-Is подтвердит …
… однако, ! … хотя это будет важно в основном для крупных и очень крупных компаний … для рядовых — это мёртвому припарка … повторюсь — лимитирующая стадия работы это не получение отчётов … !!!
… вот …
п.с. ускорение отчётов — проще достигуть оптимизацией базы… нужными и точечными данными и их получением (а не тащить всЁ ради не понятной универсальности) …
… вот …
(36) Итак , сравнение быстродействия двух отчетов. Сравниваются :
1. Отчет , прикрепленный к текущей теме (ОборотыСчетаБП1_6.erf)
2. Типовой Отчет конфигурации БП , прикрепленный в (36) и исправленный Alexk-is. Расчет и запись параметров расшифровки удалены из типового отчета.
1с Предприятие 8.1. SQL-вариант. БП 1.6
Настройки для п.1. :См.Рисунок темы третий сверху. Дополнительно :
Отметки у подчеркнутых красным группировок сняты.
У группировок СчетКтКорр и СчетДтКорр установлен тип «Иерархия»
(разворачивать колонки будем только по корр.счетам и корр.субсчетам,
выводим все субконто основного счета)
Настройки для П.2:
Установлены отметки «По субсчетам» и «По корр.субсчетам».
Выводить будем все субконто основного счета.
Для п.1. и п.2. устанавливается один и тот же счет (например счет -группа 62).
и один и тот же период (например, квартал).
По п1. и п.2. запуск осуществляется по 3 раза подряд в отдельных сеансах 1с Предприятия.
Результаты тестирования :
п.1 — 20 сек
п.2. — 37 сек
Проигрыш п.2. в 1.8 раза.
Вопрос : откуда могло взяться соотношение (36) , приведенное Alexk-is :
п.1 — 39 сек
п.2 — 45 сек ?
Предположительный ответ :
Если в настройках п.2 убрать отметку «По субсчетам корр.счетов» ( уменьшаем как минимум в два раза количество колонок) , а настройки п.1 оставляем без изменений то получим :
п.1 — 20 сек
п.2 — 24 сек.
Получается похожее соотношение , как Alexk-is
(40) …(51) … )))
… идём сюда и смотрим рисунок … экономический расчёт … ))) … вот …
(52) Шепот…прости, но расчет твой устарел… В 1с 8.2 в режиме управляемых форм все делается через СКД…
Плюс не забывай о самообразовании
(53) … дык не вопрос … вопрос «мы не рабы, рабы немы» …
(54) … дык зачем учиться не тому … и за чей счёт … ??? … если предприятие «лох» … то это его проблемы … пусть вон «бумагу» и «катриджи» экономят …
… вот …
(55) Ты не увиливай. Не спихивай на дурное предприятие .
Вопрос лично к тебе , как к специалисту : должен ты знать СКД или Нет ?
(56) … я бы хотел, как Абадонна … овладеть прямыми запросами … а СКД, ваше буду знать только по-необходимости, для работы в 1С …
… а ещЁ лучше вернуться в «семёрку» а эту «восьмёрку» послать … причём в очень НЕэтичное место и в очень НЕэстетичной манере …
… ВОТ …
… восЬмёрка своими «бантиками» …. уже достигла уровня своей НЕкомпетентности …
…
(58) «Как Абадонна» — это хорошо.
Только вот с «прямыми запросами» ты чего -то недопонял.
Соединения ADO — к базе SQL в 8-ке для стандартных задач учета просто НЕНУЖНЫ.
Ничего не дают и ничего не ускоряют.
(59) … спорить не буду … тут мои знАния никакие … но думается мне, по просмотру исследований Трактора (вроде) преобразования запросов в 1С всЁ таки хромает … зато порог вхождения в «запросы» минимальный … вот …
п.с. при этом мы же знаем что 8 — ка … это бантики … хоть и крАААсивые … однозначно … !
…
(60) У Трактора идёт обсуждение нюансов преобразования строки запроса 1с в строку запроса SQL. Этот познавательный процесс никакого практического значения для стандартных учетных задач не имеет. Придется использовать стандартные запросы и СКД.
(61) … что я могу тут сказать … ? … надо кого-то позвать … спросить … ! … вообщем кто знает … вот …
(62) Верь мне Шепот. Никого не зови.
(63) … верю … но если данные из трЁх разных источников совпадают — ВЕРЮ в тройне … ))) .. .вот …
(64) Браво !
(63) Шепот, не верь ему. Он тебя запутает.
Речь о чем идет (заметь, аватарка гласит «Мы пишем запросы»). О том, что восьмерочный механизм СКД настолько приличен, что восьмерочный же кодинг не оправдывает себя — при изрядных трудозатратах выигрыш весьма невелик. Сравнение с семеркой столь же неуместно, как сравнение Виндов с ДОСом — Ясно жде что в ДОСе тот же функционал на порядок быстрее и на два порядка менее требователен к памяти. Однако ж — прогрессьь…
(47) Нет. Всё не так. Я всё сделал по инструкции.
Переделал отчеты под УПП 1.2.
Результаты:
2. 23,172 сек
6. 11,891 сек
Разница более чем в 2 раза
Из-за чего такое различие по времени выполнения между БП и УПП? Думаю разница в составе данных, попавших в отчет. Соответственно для одного предприятия будет значительная разница, а для другого разницы не будет вообще или она будет не столь значительная.
(37)
Игорь.
Метаданные в кэше это хорошо. Но если из-за этого «время исполнения отчета существенно меньше»(с), то это говорит об очень плохой реализации алгоритмов работы с метаданными. Сомневаюсь я в этом. Думаю, сильнее влияют на время повторного запуска, именно, сами данные. Про третий запуск можно не рассуждать. Но надо сказать — какой отчет запускается третьим. Т.е. если нет желания «перезагружать систему», то можно запустить несколько раз с чередованием два разных отчета. А по уму — надо запускать три раза каждый отчет с «перезагрузкой системы» перед каждой серией тестов. А потом внимательно (вдумчиво) смотреть на числа.
P.S. Извините меня, что я донимаю Вас этой информацией (вопросами). Но сам провести тесты не могу, т.к. у меня нет компьютера. А было бы интересно посмотреть на результат замеров.
(73) Что метаданные не грузятся при запуске Предприятия и подгружаются лишь по мере обращения к ним — это написано в документации. Думаю отыскать это можно.
После первого запуска , второй и последующий запуски отчета одинаковы по времени выполнения — это факт ( и при файловом и SQl- варианте).
Всё остальное — мои рассуждения. Не меньше , но и не больше.
Это я так .. для прояснения ситуации.
(72) Я так понимаю , что для УПП ты получил аналогичные результаты тестирования, что и я в (47) , а именно :
Типовой отчет «Обороты счета», в котором для ускорения выключена расшифровка, работает примерно в 2 раза медленнее , чем представленный в текущей теме отчет , использующий СКД.
Теперь о тестировании на БП.
Почему получаем различные результаты ?
Объяснение :
— звучит для меня невероятно ( Для счетов в которых есть какие -то обороты ( 5-6 колонок счетов для дебета и кредита) — и строк в отчете не менее 80-100)
Считаю , что в этом случае представленный отчет и для БП должен выиграть в быстродействии как минимум 1.8-2.0 раза.
Без третейского судьи тут никак.
(74)
Игорь.
Опят о разном говорим. 🙁
Подгружаются метаданные — естественно и логично.
Но я предполагаю не значительное влияние этого на первый запуск.
По сравнению с СУБД-шным+ОС-вым кэшированием.
Завяжем и эту тему…
(76) Да нет . Об одном и том же.
В (75) лишь разделил свои размышления и факты.
А перезапустить систему перед отчетом нетрудно. После презапуска системы показывает такое же время при первом запуске и при втором как и до перезапуска системы.
(77)
Ох. О разном… 🙁
Вы писали в (37): «при втором запуске время исполнения отчета существенно меньше.». А в (77) — обратное. Завязываю тему. Не буду Вас отвлекать от дел…
(78)
В (37) речь шла об одном сеансе 1сПредприятия , в котором последовательно дважды запускался отчет.
В (77) сраниваются по быстродействию :
1. Первый запуск сеанса 1сПредприятия : дважды запускается отчет.
— Выход из сеанса
2. Второй запуск сеанса 1сПредприятия : дважды запускается отчет.
И говорится о том , что в п.1 и в п.2 время исполнения отчетов одинаковое.
(10) Да и да. Пропорции ~ сохраняются в обоих случаях
(80) В скобочках замечу, что при модификации типового отчета «Обороты счета» ты не только в текстах модуля убирал расшифровки , но и оптимизировал типовой код вывода отчета методами описанными в «Заметочках по 8-ке».
Но это даже хорошо ! Стало ясно еще более отчетливо :
как угодно оптимизированный «ручной» кодинг проиграет по быстродействию СКД.
(79)
Игорь.
Эти фразы не несут разного смысла:
«последовательно дважды запускался отчет»
«дважды запускается отчет»
А другие фразы, думаю, несут разный смысл:
«перезапустить систему»
«перезагружать систему»
«выход из сеанса»
(86) Ок.
(81) Тут такое дело. Есть подозрение, что СКД выигрывает при большом количестве пустых ячеек. В БП пустых и заполненных было ~ поровну, а в УПП пустых было в 2 раза больше.
Насчет оптимизации. Да я отпимизировал существующий код. Но кто сказал, что методика используемая для построения типового отчета является наиболее эффективной? Может проблема здесь? Ведь в типовом отчете данные собираются двумя запросами, а в СКД одним. Уверен, что при достаточной проработке методики формирования отчета можно значительно повысить скорость вывода данных в отчет и без СКД. Например, можно попросить Душелова написать ВК 🙂
(88) Уже что-то !
Придётся проверять так : насоздавать «лишних» операций так , чтобы все колонки дебета и кредита были заполнены и тогда уже сравнить СКД и твой отчет с отключенными расшифровками.
Правда , сразу нужно отметить :
Расшифровки, замедляющие быстродействие типового отчета в 2раза (!), всё равно нужны и отключать их при сравнении некорректно . Ведь в СКД расшифровки -то используются и оптимальная работа с расшифровками — это одно из больших преимуществ СКД перед «ручным» кодингом.
При корректном сравнении даже как угодное оптимальные расчет и запись расшифровок займут время и «кодинг» все равно проиграет в разы.
Мой Прогноз : ВК не спасет , Душелов не спасет … и никто не спасет .
(89)
«… и никто не спасет»(с)
2002 год и раньше 😉
(90) Владимир, Вы зачем «смущаете своим разумением» неокрепшие умы 1с-ников ?
Нехорошо это.
Тут бы с MS SQL, Oracle, DB2 (реляционных по сути) разобраться хоть как нибудь ,
а нам предлагается как спасение — «Постреляционная СУбд Cashe5» , требующая своего языка доступа к Базе данных (SQL- на свалку, все реляционно ориентированные приложения , стало быть тоже). Вот заживём !
Чем черт не шутит , но что-то с 2003г (время написания статьи) я не слышал чтобы Cashe5 отгрызла хоть какой-то кусочек рынка (для бизнес -приложений) у тех же MS SQL, Oracle, DB2 .
Может подождем пока Cashe5 сдохнет… или завоюет весь мир ?
Тогда и обсудим чем она хороша (плоха) ?
(91)
Неокрепшие умы могут не окрепнуть, а задубеть.
Вот это, действительно — «Нехорошо».
Я уважаю Ваш «конкретный» (прагматичный) подход к нашим задачам.
Но не видеть (или не знать), что «…использование реляционного подхода не столь эффективно в таких приложениях, как АСУП,…»(с) — это ОЧЕНЬ «Нехорошо».
Разработчики 1С-ов — видят и знают. Но решают проблемы «реляционного подхода» за деньги пользователя (покупателя). А мы публикуем и долго обсуждаем статьи по алгоритмам из двух циклов. А это ОЧЕНЬ грустно…
(92) Я тоже , кстати, обратил внимание на эту фразу :
Сильно.
Тот самый случай , когда невозможно определить :
То ли очень глупо , то ли очень умно.
А то , что мы обсуждаем алгоритмы из двух циклов… Это правда.
Когда-то давно я взгрустнул познакомившись с бухгалтерскими задачами.
Но потом как-то прошло…
(93)
Я не говорю про «бухгалтерские задачи» из двух циклов.
Тема моих высказываний: «Проблема перекрестных таблиц ( то бишь таблиц с динамическими колонками) в СУБД обсуждалась где-то в середине 90-х годов»(с)(7).
Т.е., опять, проводим «научные» исследования на пустом месте, когда «Мы пишем запросы!». Нет никакой проблемы с динамическим колонками — два простейших цикла…
(94) Мы говорим о разном.
Вы мне — алгоритм из двух циклов не стоит обсуждения.
Я Вам про тему статьи : кодинг из двух циклов по быстодействию уступает встроенному средству платформы под названием СКД.
(95) Что настройка СКД, что результат ручного кодинга — и то и другое 1С преобразует в СУБД-шный запрос. Твое утверждение сводится к тому, что в случае СКД платформа действует оптимально, а ручные циклы обрабатывает коряво. Вполне возможно, что СКД-шный внутренний язык запросов является тем промежуточным состоянием, к которому приводятся «ручные» запросы — ясное дело, на промежуточные преобразования потребуются дополнительные ресурсы.
То есть вопрос — в реализации платформы на практике. Или — насколько 1С-ные разработчики восприняли теорию, которая упомянута в (94).
(96) Код типового отчета «Обороты счета» в БП 1.6 можно условно разделить на два этапа :
— выполнение двух запросов, получение их результатов.
— собственно «ручной» кодинг : цикл, в котором построчно выводятся результаты
запроса в выходной табличный документ (по вашему «Таблица»).
Аналог этого отчета на СКД содержит , грубо говоря, те же запросы, а вот обработку результатов запроса и рисование отчета производит внутренними механизмами СКД.
Никакого выигрыша в скорости выполнения запросов («первый этап») при использовании СКД мы не имеем. Выигрыш имеем за счет реализации «второго этапа» : обработка результатов запроса и рисование отчета.
Никакого своего , «внутреннего» языка запросов СКД не имеет.
А в (94) Владимир говорит о чём -то своём … далёком и отвлечённом.
P.S. Я изложил упрощенно-грубо , в первом приближении , необходимом для понимания.
(88) Так и есть !
При сравнении двух отчетов , отключено разворачивание по Кт. Включено только по Дебету. «Лишними» операциями добились заполнения всех колонок счетов дебета , Получили таблицу 2500 строк — 25 колонок ( из которых полностью заполнены 20 по счетам Дебета).
Результаты :
Твой отчет 12 сек
Мой отчет 10 сек
Вывод : в предельном случае (когда все колонки заполнены на 100% ) отчет с отключенными расшифровками проиграет те самые 20%. ЧТо подтверждает результат , который ты получил ранее.
(97)
«Владимир говорит о чём -то своём … далёком и отвлечённом»(с)
Игорь.
Я уже и не знаю о чем говорить. 😉
Говорю о «теории» про два цикла — мимо.
Предлагаю провести конкретные замеры — мимо.
Предлагают разобраться в сути ускорения — мимо.
И постоянно, с Вашей стороны, «крепкая конкретика», снабженная «качественными» оценками, типа:
«… многократно проиграет в быстродействии.»(с)
«… алгоритм , на мой взгляд, для больших таблиц выиграет у любого другого.»(с)
«… размер таблиц … может быть как угодно большим .»(с)
«… таблицы … могут быть очень большого размера.»(с)
«… для как небольших, так и очень больших объемов данных (свыше 120-150 ГБ).»(с)
На мой взгляд это гадание «на кофейной гущи». 🙁
Я понимаю, что вы поставлены («домиком») в условия обязательного использования «1С 8.х» и «запросов». Типа, жизнь заставляет… Но, Вы, как мне показались, пытаетесь осмыслить внутреннее устройство системы, а не тупо жать на кнопки. И это вызывает уважение с моей стороны. И, извините, вызывает желание «подтолкнуть» Вас к более глубокому анализу — зачем, где, когда и почему «Мы пишем запросы!»(с). Я постараюсь больше этого не делать…
(99) Прочитал цитаты и улыбнулся. Посреди Вашего поста (вежливо — расплывчато-уклончивого) смотрятся они особенно диковато.
Мы расходимся с Вами в том , как вести дискуссию в теме.
Я считаю , что автор темы должен играть первым номером. Что это значит ?
Автор темы должен делать утверждения. Они могут быть и неверными. Но они должны быть. Далее автор должен представить конретную разработку , подтверждающую его правоту. Далее автор должен привести сравнительный анализ (с чем -либо), сделать выводы. Причем четкие , определенные — такие, которые можно было бы оспорить.
Ясная, определенная позиция — это клад для оппонента , который хочет эту позицию опровергнуть.
Действительно , возьмем фразу- утверждение (извиняюсь за самоцитирование) — «… многократно проиграет в быстродействии.»
Для чего она ? — Она для оппонента, желающего её опровергнуть.
Для этого есть все возможности — в теме-то указано что сравнивать и как сравнивать.
Смотри (88).
Именно этим автор выказывает уважение возможным оппонентам , т.е. честной игрой по правилам. А колкости можно пропукать мимо глаз …
Я часто (бывает и не по делу) с удовольствием выступаю в темах Арчибальда. Почему ?
Потому что он играет по тем же правилам.
Когда же автор ведет себя безопасно , не делает утверждений , (пусть резких, пусть неверных) , а делится размышлизмами , которые невозможно ни подтвердить, ни опровергнуть — тема получается ни о чём и быстро вянет.
Делайте утверждения , Владимир !
(100)
«Когда … автор ,,, делится размышлизмами …»
— Тем самым, автор предлагает собеседнику поразмышлять, т.е. — думать.
«Я считаю , что автор темы должен…»
— Да. Я заметил, что Вы считаете, что все должны излагать свои мысли, так как это Вам хочется. Ваше право — считать. Право других людей — игнорировать Ваши «хотелки».
«Мы расходимся с Вами в том , как вести дискуссию в теме.»
— А мы с Вами и не ведем дискуссию. Её, просто, не существует. Пример. Два специалиста обсуждают принципы работы пульта ДУ для телевизора. Один говорит о функциональной нагрузке кнопок (включение, регулятор громкости, выбор каналов и т.д.), а другой о способе передачи информации от ДУ к приёмнику (протокол, физика, принципиальная схема устройства, элементная база и т.д.).
«Делайте утверждения…»
— Игорь. А мои фраза, типа: «Такой задачи (проблемы) не существует». Это, разве, не утверждение. Или надо действовать проще — поставить «минус». Или сказать, что «Автору нужно помочь с выражением того , что он хочет сказать.»(с).
Игорь.
Поиск «волшебных палочек» для «автоматизации» труда программиста ведётся с момента появления самой профессии «программист». Язык запросов — одна из таких «палочек». Весь мир (думающая его часть) уже давно пришла к выводу, что эта палочка является зубочисткой. А Вы с 1С-ами пытаетесь ковырять этой палочкой в другом месте. Это не гигиенично… 😉
P.S. Попробуйте эту «колкость пропустить мимо глаз». 😉
(101) Слово за слово , глядишь , и перейдем к делу. Берем предложение :
Утверждение , которое здесь приводится ни опровергнуть , ни подтвердить нельзя.
О чем спорить -то ?
Зубочистка или нет ? Весь мир или не весь мир ? Гигиенично это или нет ?
Всё пустое, всё мимо …
А Вы начните свою статью словами » Эх, вы одинесники… тёмные и дремучие »
(.. это так — для затравки разговора , чтобы народ подтянулся).
Затем приведите пример , который люди могут потрогать , пощупать , попробовать, сравнить.
Сделайте выводы о гибельности 1с-овского курса, которые можно будет опровергнуть ( плохо -хорошо, быстро-медленно). И тогда мы поспорим .
А сейчас что ? (101) — это мило , забавно… НО НЕ ЦЕПЛЯЕТ.
(101) До завтра. Убегаю.
(102)
«Всё пустое, всё мимо …»
— У Вас в глаз соринка попала в форме «восьмерки». Протрите глаза. Вы на мои «статейки» и «поделки» смотрели?
«О чем спорить -то ?»
— Именно — так. Спора не может быть. Опять повторю — мы говорим о разных вещах. Думаю, пред началом спора (обсуждения) имеет смысл договориться о предмете спора.
«А Вы начните свою статью словами…»
— Не понял! Я написал статью? Или Вы написали статью? Или Вы мне предлагаете написать статью? Лично я не вижу статьи в обозначенной Вами теме «Мы пишем запросы!». Предмета для статьи — НЕТ. Я не пишу запросы. И у меня не возникает никаких проблем (вопросов) для широкого обсуждения простейших алгоритмов реализации моих задач. А у Вас возникает. Почему?
«Сделайте выводы о гибельности 1с-овского курса…»
— Не могу. Т.к. этот курс будет жить долго и счастливо. Как и многие другие «курсы» для массового потребления, типа MS Windows, SQL серверов, алкоголя, наркотиков и т.д. 😉
«НО НЕ ЦЕПЛЯЕТ»
— Смените продавца «цеплялки». 😉
(97)
Таки оформительский бантик?
(115) в приведенной тобой цитате есть слова «обработка результата запроса» , т.е. внутренними механизмами платформы реализация п.1,2,3 из (111).
(115) Разница есть и на первом этапе. В типовом отчете используется 2 запроса, а в СКД один. Не знаю почему разработчики фирмы 1С не смогли обойтись 1 запросом.
(98) В СКД расшифровки есть, но какой в них прок, если в качестве расшифровки по сумме открываются элементы справочников контрагенты или договоры.
(118) Я тоже думаю, почему в типовом отчете они сделали два отдельных запроса, а не один : левое соединение двух этих отдельных запросов ? Что-то их оттолкнуло от этого шага.
(119) Это уже другой вопрос. к быстродействию выполнения отчета не имеет никакого отношения.
Обработку расшировки при выборе ячейки мы можем сделать какой угодно : по элементу расшифровки определяя все текущие необходимые значения.
(98) Возможно эти 20% из-за второго запроса в типовом отчете.
+119 Расшифровки тоже можно формировать более эффективными методами. Почему это не сделано? Наверное всё дело в пользователях — они не жалуются. Есть варианты: не пользуются этим отчетом; пользуются этим отчетом крайне редко; пользуются другим отчетом, который шевелится побыстрее.
(121) В СКД расшифровки аналогичной типовой ведь нет. Ну, нет её. Нет…
(118) Хотя , понятно что левое соединение двух запросов будет выполняться гораздо медленнее , чем два запроса по отдельности. И выходная выборка в первом случае значительно превосходит по размеру сумму двух выборок во втором случае.
(123) Не понял . Что значит «нет» ? В моём отчете ? или в типовом БП 2.0 ?
В моём отчете и не планировалось его делать. Зачем ? Цель была другая. Но ничто не мешает сделать расшифровку в моем отчете , аналогичной в типовом отчете БП 1.6.
(124) Самое простое, что приходит на ум, сделать второй запрос по результатам первого запроса, а не по первичным данным.
(125) Слова, слова… Но за словами я так и не понял, что расшифровки так и не будет в СКД? Тогда можно померяться в быстродействии с расшифровками — тоже тема: Расшифровки СКД против расшифровок типовых отчетов.
(127) Ну что ж. Поехали разбираться.
Расшифровка в СКД в моём отчете уже ЕСТЬ !
Всем ячейкам табличного документа поставлен в соответсвие «ЭлементРасшифровки». При двойном клике на ячейке уже выведенного отчета — я не использую всех возможностей расшифровки и не строю другие отчеты , хотя с помощью переданного в процедуру «ЭлементаРасшифровки» можно получить все необходимые данные для построения подчиненного отчета.
Зачем ? К быстродействию уже выведенного отчета это не имеет никакаго отношения.
Замерить и узнать :
можно уже сейчас. Запусти мой отчет и типовой . Сравни результаты. Вот и всё.
При использовании СКД после выполнения отчета каждой ячейке выходного табличного документа ставится в соответсвие «ЭлементРасшифровки». И когда пользователь выбирает ячейку (нажимает Enter или двойной клик) на ней — ему передается этот самый «элемент» как параметр. По этому элементу методами ПолучитьПоля или Получить Родителя можно определить либо все поля текущей группировки или элемент расшифровки верхнего уровня .
Извиняюсь. Это я, на всякий случай, своими словами передал содержание документации.