gifts2017

Разработка отчета СКД с использованием заглушек наборов данных

Опубликовал Пишу код как картины (yurii_host) в раздел Программирование - Практика программирования

Данный метод универсальный, понятный и простой в реализации. Я сам его постоянно использую при разработке сложных отчетов. Возможно, найдутся разработчики, которые также найдут его полезным для себя

Постановка задачи

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


Решение

Стандартный подход к решению такой задачи - итерационный. На каждой итерации мы пишем запрос или его часть, затем дорабатываем ресурсы, вычисляемые поля, структуру. Затем дописываем запрос. И так по кругу.

На некоторых итерациях выясняется, что нужно менять структуру полей запроса. При этом переделывать уже написанные запросы бывает очень трудоемко. Иногда также приходится менять структуру наборов данных.


Чтобы упростить решение задачи, можно на первом этапе абстрагироваться от запросов к таблицам базы данных. То есть организовать заглушки наборов данных, возвращающих ожидаемый нами результат. Опираясь на заглушки уже можно описать вычисляемые поля, ресурсы, структуру данных. А после уже переходить к написанию запросов. Если на какой-то из итераций понадобится изменить структуру полей набора данных, то сделать это в заглушке не составляет большого труда.


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


Заглушки

Заглушки описываются в виде запросов, возвращающих константные значения.



Пример из практики


Данный пример был мной написан для одного из разработчиков, которому потребовалась помощь в выводе отчета. При этом мы находились в разных местах и у меня не было возможности подключиться к базе заказчика, на которой необходимо было реализовать отчет. Это я акцентирую внимание на еще одной области применения данного метода.


  1. Пусть необходимо реализовать отчет следующего вида

  • Порядок показателей должен быть быть постоянным

  • У каждого показателя свой алгоритм расчета

  • Показатель Количество бункеровок является суммой бункеровок по портам

  • Сворачивание портов необязательно и заказчику оно не нужно



  1. Изначально понятно, что будем использовать три набора данных через объединение. Создадим их с заглушками запросов. Порты пока откладываем



  1. Сразу можно вывести то, что получилось в отчет



  1. Дальше выводим порты. Для этого нужно немного исправить третий набор данных

Имеем результат

 

  1. Делаем отступ слева у портов. Для этого сначала добавляем признак ЭтоПорт в запрос


Далее используем условное оформление, предварительно добавив порт в группировку


  1. Чтобы скрыть количество в заголовке, пишем пробел в заголовок

 


  1. После этого имеем результат как на картинке из п.1. Теперь структура ожидаемых полей запроса известна, можно в каждом наборе данных последовательно описать запрос вместо заглушки.


Описанное решение не является идеальным. Оно приведено здесь только для демонстрации использования запросов-заглушек. На самом деле практическая задача была чуть сложнее, но некоторые детали опущены, т.к. они не имеют отношения к теме данной публикации. Прототип отчета приложен к публикации.


Заключение

Для генерации запросов-заглушек удобно использовать инструмент, приложенный к этой публикации или написать его самостоятельно. Суть его очень простая: описываем таблицу в табличном макете и по ней генерируем текст запроса-заглушки

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Прототип отчета к статье
.erf 8,16Kb
25.06.16
2
.erf 8,16Kb 2 Скачать
Инструмент для генерации запросов-заглушек (ОФ+УФ)
.epf 12,58Kb
25.06.16
5
.epf 12,58Kb 5 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Алексей Ларин (roofless) 27.06.16 15:09
Дополнительным плюсом в таком подходе является то, что если в базе нет всех нужных нам данных, то разработка не задерживается, мы можем сделать самую трудную работу без них.

самое трудное - это добавить в базу нужные данные =(

перефразирую - "Если в базе нет нужных нам данных, то лепим заглушки", верно?
Прототип запроса писать нужно, имхо. Иначе, как мы узнаем, что этих данных нет?) сразу наверное абстрагироваться не стоит
2. Пишу код как картины (yurii_host) 27.06.16 15:38
(1) roofless, часто бывает так, что данных в базе нет, потому что их туда трудно набить. Например, данные добавляются в регистры документами, которые еще находятся на стадии разработки. Или данные добавляются в регистр в результате сложного расчета (например, по себестоимости). Или я пытаюсь добавить данные в таблицы базы и начинают сыпаться ошибки, которые ко мне не имеют отношения. Или какие-нибудь ограничения по правам. Или требуется ввести еще кучу предварительных документов, чтобы добавить записи в нужный тебе регистр при проведении. Тогда заглушки очень даже полезны.

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

Но если отчет простой, и структура вывода линейная, и изначально понятно какие поля должны быть в запросе - то не имеет смысла заморачиваться с заглушками
roofless; +1 Ответить
3. Яков Коган (Yashazz) 28.06.16 14:52
Лепя заглушки, не забывайте о потенциально пустых реквизитах и о реквизитах составного типа... Особенно весело делать это для характеристик)
4. Пишу код как картины (yurii_host) 28.06.16 15:14
(3) Yashazz, часто такое бывает?
5. Марина Чирина (chmv) 29.06.16 13:00
Неправильный подход изначально
6. Пишу код как картины (yurii_host) 29.06.16 13:08
(5) chmv, спасибо за проявленный интерес.
Не могли бы поподробнее уточнить, что конкретно вы считаете неправильным?
7. Азбука Морзе 08.07.16 10:38
Ну не знаю... По-моему, чтобы получить недостающие данные, гораздо нагляднее да и проще использовать таблицы значений в качестве параметров к запросу.
8. Яков Коган (Yashazz) 08.07.16 18:35
(4) yurii_host, как будете делать заглушку для субконто?
9. Пишу код как картины (yurii_host) 09.07.16 01:24
(8) Yashazz, если я правильно понял вопрос, то его можно переформулировать так:
как сделать заглушку для набора данных, одно или несколько полей которого должно возвратить субконто, причем необходимо не просто вывести его в отчет, а также обращаться к некоторым свойствам через точку, например, при описании структуры?
ответ - можно попробовать возвращать поле через ЗНАЧЕНИЕ(Предопределенное значение или пустая ссылка). Но нужно смотреть по ситуации и, возможно, в некоторых случаях методика, описанная в данной публикации, вам не подойдет
10. Константин Ермоленко (Quasar) 15.08.16 12:39
(7) Азбука Морзе, а в чем принципиальное отличие? Да и к тому же данный метод позволяет написать заглушку 1 раз прямо в тексте запроса. А не подкидываться каждый раз с формированием таблицы значений и передачей ее в качестве параметра.
11. Владимир Кривотулов (Onwardv) 15.08.16 13:13
Да, удобно.
Я тоже такой подход использую.
Но заглушкой называю другое :). : Конструкцию вида ЛОЖЬ И
Когда делаешь отчет по ТЗ(тех.задание), где множество временных таблиц, а потом тз поменялось и какая-либо выборка уже не нужна (возможно вернут). Вот там и добавляем в "где" эту заглушку.
ГДЕ ЛОЖЬ И
   старые условия.


Тем самым быстро убираем выборку, не переделывая все последующие пакеты. Время на такой пакет 1с практически не тратит.

Также использую для поиска критичных для быстродействия соединений при оптимизации разветвленных запросов. Например, есть запрос с множеством левых соединений, который пытаемся оптимизировать. Берем и отрубаем самый подозрительный заглушкой :
.....
Левое соединение регистрСведений.НашСуперРегистр.Срезпоследних()
по ЛОЖЬ И
 старые условия

....
если скорость выполнения увеличилась не существенно, тогда заглушку убираем и ставим на другое подозрительное.
Т.е. ищем действительно самые долго выполняющиеся соединения и оптимизируем их, а не все подряд.
12. Сан Саныч (herfis) 15.08.16 14:44
Трудность заключается в том, что нам изначально непонятна структура полей, которые нужно получить из наборов данных, какие поля будут вычисляемыми, можно ли посчитать ресурсы формулами или же их придется вычислять в запросах.

Фигня какая-то. Никогда таких трудностей не возникало.
Обычно предельно четко ясно, какой минимально необходимый набор данных позволит получить конечный результат. И разработка источника данных отделена от разработки настроек.
Какие, нафиг, итерации? Откуда? Только не стоит вещать, что я не работал с "по-настоящему сложными отчетами" или что я какой-то там уникум.
Единственную пользу вижу - возможность отладить в консоли схему, в которой будут использоваться в т.ч. и "боковые" наборы данных (из ТЗ, например). Тогда в самом деле эффективно воткнуть "заглушку" в виде набора аналогичной структуры, которую в "боевом" варианте можно поменять "одним движением".
13. Пишу код как картины (yurii_host) 15.08.16 21:02
(12) herfis, спасибо за отзыв.
В статье описан прием, который лично мне помогал решать большое количество СЛОЖНЫХ задач.
Кроме того, перед написанием статьи я поделился им с несколькими коллегами. Некоторые из них тоже стали его применять, а некоторым этот прием не подошел. В общем это нормально - всем угодить невозможно. Кроме того несколько пользователей Инфостарта также нашли описанный способ полезным для себя. Данная статья выкладывалась в первую очередь ради них.
14. Hromov Anton (hromovanton) 12.10.16 10:44
(11) Onwardv, спасибо за пример с заглушкой в соединениях запроса!
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа