Разбиение текста запроса на функции

28.10.16

Разработка - Запросы

Хочу посвятить публикацию одному приему, который я впервые увидел в типовой ерпи. Если честно, описание идеи довольно короткое, и слабо тянет на целую публикацию. Но я намеренно выделил ее в отдельную статью, чтобы акцентировать на ней внимание, т.к. считаю, что данная техника СУЩЕСТВЕННО повышает читаемость, а также заставляет структурировать тексты запросов.

Если вы уже давно работаете с УТ 11 или ERP, то скорее всего не найдете для себя ничего нового в этой статье. Но есть разработчики, которые еще не успели плотно поработать с упомянутыми конфигурациями, возможно для них данная информация покажется полезной.

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


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

Пример 1

ТекстЗапроса =
	ТекстЦеныИнициализация() + ";" // подготавливаем временные таблицы втПериодыЦен, втДисконтныеКарты, втПорогиСкидок
	+ ТекстОписаниеЕжедневныйПрайсЛист()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныНаТоварыВОстатках() // использует ПрошлыеПоступления
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныДоставки()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныУслугСборки()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныТоваровПоРаспродаже()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныНаУцененныеТовары()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныНаАлкогольнуюПродукцию()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныИмпортныхТоваров()
	+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЦеныНаТоварыИзКомбоакций()
	+ ТекстИндексы;
МВТ = Новый МенеджерВременныхТаблиц;	
Запрос = Новый Запрос(ТекстЗапроса);
Запрос.УстановитьПараметр("ДатаПрайса", Период);
Запрос.УстановитьПараметр("МассивОрганизаций", МассивОрганизаций);	
Запрос.МенеджерВременныхТаблиц = МВТ;
Запрос.Выполнить();

Код похож на оглавнение в книге. Текст сложного запроса складывается из элементарных кусочков.

Пример 2

Приведу отрывок кода, где аналогичный прием используется при проведении документов в новых типовых конфигурациях (например, ERP, УТ 11)

Модуль менеджера нашего документа

////////////////////////////////////////////////////////////////////////////
// Создадим запрос инициализации движений

Запрос = Новый Запрос;
ЗаполнитьПараметрыИнициализации(Запрос, ДокументСсылка);

////////////////////////////////////////////////////////////////////////////
// Сформируем текст запроса

ТекстыЗапроса = Новый СписокЗначений;
ТекстЗапросаТаблицаЗаказыПоставщикам(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаРасчетыСПоставщиками(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаДвижениеТоваров(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаТоварыКПоступлению(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаЦеныНоменклатурыПоставщиков(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаОбеспечениеЗаказов(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаОбеспечениеЗаказовРаботами(Запрос, ТекстыЗапроса, Регистры);

ПроведениеСервер.ИницализироватьТаблицыДляДвижений(Запрос, ТекстыЗапроса, ДополнительныеСвойства.ТаблицыДляДвижений, Истина);

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

Плюсы такого подхода:

  • понять, что происходит, можно не заглядывая в конструктор запроса
  • текст каждого кусочка можно открывать конструктором запроса
  • легко добавлять комментарии, которые не удаляются конструктором запроса
  • у каждого кусочка собственное имя, по которому можно понять, что он выполняет
  • можно именовать кусочки запроса в конструкции "ОБЪЕДИНИТЬ ВСЕ"
  • удобно читать, т.к. сначала мы видим имя выборки, а затем можем к ней перейти
  • количество кусочков запроса не ограничено, как в подходе со временными таблицами, когда на закладках конструктора при большом количестве временных таблиц их имена не читаются

Минусы:

  • труднее поддерживать корректный состав полей между разными запросами
  • получить полный текст запроса можно только с использованием точки останова - что не очень удобно

На мой взгляд, плюсы существенно перевешивают минусы, и сложные запросы действительно упрощаются.

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122086    670    389    

714

Для чего используют конструкцию запроса "ГДЕ ЛОЖЬ" в СКД на примере конфигурации 1С:ERP

Запросы СКД Платформа 1С v8.3 Запросы Система компоновки данных 1С:ERP Управление предприятием 2 Бесплатно (free)

В типовых конфигурациях разработчики компании 1С иногда используют в отчетах, построенных на СКД, такую конструкцию, как "ГДЕ ЛОЖЬ". Такая конструкция говорит о том, что данные в запросе не будут получены совсем. Для чего же нужен тогда запрос?

13.02.2024    5742    KawaNoNeko    23    

23

Набор-объект для СКД по тексту или запросу

Запросы СКД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Есть список полей в виде текста, или запрос - закидываем в набор СКД.

1 стартмани

31.01.2024    2000    2    Yashazz    0    

29

Запрос 1С copilot

Инструментарий разработчика Запросы Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Пишем на человеческом языке, что нам надо, и получаем текст запроса на языке 1С. Используются большие языковые модели (LLM GPT) от OpenAI или Яндекс на выбор.

5 стартмани

15.01.2024    6284    31    mkalimulin    25    

50

PrintWizard: поддержка представлений ЗУП в конструкторе

Инструментарий разработчика Запросы Платформа 1С v8.3 Бесплатно (free)

Одной из интересных задач, стоящих в процессе разработки, была поддержка механизма представлений в ЗУП. Но не просто возможность исполнения запросов с ними. Основная проблема была в том, чтобы с ними было удобно работать, а именно: создавать, модифицировать и отлаживать. Кратко о том, что в итоге получилось...

14.12.2023    1742    vandalsvq    7    

29

Объектная модель запроса "Схема запроса" 2

Запросы Платформа 1С v8.3 Запросы Конфигурации 1cv8 Бесплатно (free)

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

06.12.2023    5386    user1923546    26    

43

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16172    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. vasilev2015 2686 13.09.16 09:32 Сейчас в теме
В ЗУП запросы разбивают по временным таблицам, значения которых передают Менеджером Временных Таблиц. Тоже вариант.
4. json 3297 13.09.16 10:44 Сейчас в теме
(1) vasilev2015, согласен, что такой подход решает проблему с понимаемостью запроса, но возникают трудности с отладкой. Если нужно отладить очередной запрос, который использует несколько временных таблиц, которые пришли через МВТ, то не получится так просто открыть консоль запроса в точке останова, т. к. в нее можно передать запрос с параметрами, но без временных таблиц.

(3) unichkin, имхо, удобнее, когда функция содержит не весь текст запроса, а только часть запроса, которую можно отдельно открыть конструктором. В этом случае с ним проще работать, т.к. можно быстрее перейти к нужному участку запроса, а также в самой этой функции можно добавлять комментарии, что тоже немаловажно в сложных запросах
2. white-mount 13.09.16 09:38 Сейчас в теме
Плюсы такого подхода:

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

Сам справочник своих "стандартных функций" удобнее хранить в нотации xml, для автоматизации построения запросов.
26. sulfur17 59 15.09.16 09:18 Сейчас в теме
(2) white-mount, можно вас попросить, расшифруйте пожалуйста о чем речь?
Давно работаю с 1С, но совершенно не понял о чем вы.
Это я о каких-то технологиях не знаю?
33. white-mount 15.09.16 12:29 Сейчас в теме
(26) sulfur17,
"white-mount, можно вас попросить, расшифруйте пожалуйста о чем речь?
Давно работаю с 1С, но совершенно не понял о чем вы.
Это я о каких-то технологиях не знаю?"

Пример от 1С - "выгрузить/загрузить в файлы", к примеру.

Уважаемый автор, yurii_host, обратил внимание на тексты "в типовой ERP", кто то задался вопросом, а как собственно движок 1С отрабатывает запросы и почему так медленно.

Разбиение текста запроса на функциональные блоки-модули позволяет не только легко стандартизовать свои проверенные модули, но и перейти на скрипты, в которые конструкции передаются в xml нотации. Такие скрипты отрабатываются гораздо быстрей штатных методов.

Основная проблема работы с запросами, хоть для файлового, хоть для sql варианта, это предварительное создание схемы выборки данных, таблицы ссылок.

Метод модульности позволяет легко визуализировать конструкцию запроса, используя графы.
Что в свою очередь упрощает конструирование или оптимизацию исходных объектов - документов, справочников, регистров и их реквизитов.
3. unichkin 1559 13.09.16 09:58 Сейчас в теме
Еще удобно выносить текст запроса в отдельную функцию, возвращающую строку. Т.е. не писать

Процедура МояПроцедура()

Запрос = Новый Запрос;
Запрос.Текст = "
// 100500 строк текста запроса
";
...
КонецПроцедуры


а вот так:

Процедура МояПроцедура()

Запрос = Новый Запрос;
Запрос.Текст = ТекстЗапроса_МояПроцедура();
...
КонецПроцедуры

Функция ТекстЗапроса_МояПроцедура()
Возврат "
// 100500 строк текста запроса
";
КонецФункции

Показать
VAAngelov; Denis S; Bazin; sulfur17; +4 Ответить
34. dj_serega 390 15.09.16 15:56 Сейчас в теме
(3) unichkin, Я в 8.3 юзаю области.
Шаблон:
Запрос<?"Имя переменной запроса:"> = Новый Запрос(
#Область Текст_запроса
"<?"", ТекстЗапроса>"
#КонецОбласти
);
<?>Запрос<?"Имя переменной запроса:">.УстановитьПараметр("", );

Результат<?"Имя переменной запроса:">Выполнить = Запрос<?"Имя переменной запроса:">.Выполнить();
Результат<?"Имя переменной запроса:"> = Результат<?"Имя переменной запроса:">Выполнить.Выбрать();
Результат<?"Имя переменной запроса:"> = Результат<?"Имя переменной запроса:">Выполнить.Выгрузить();
Показать

Результат:
ЗапросПримерЗапроса = Новый Запрос(
#Область Текст_запроса
""
#КонецОбласти
);
ЗапросПримерЗапроса.УстановитьПараметр("", );

РезультатПримерЗапросаВыполнить = ЗапросПримерЗапроса.Выполнить();
РезультатПримерЗапроса = РезультатПримерЗапросаВыполнить.Выбрать();
РезультатПримерЗапроса = РезультатПримерЗапросаВыполнить.Выгрузить();
Показать
nihfalck; +1 Ответить
38. unichkin 1559 18.09.16 23:16 Сейчас в теме
(34) dj_serega, мне кажется создание объекта запроса с параметром конструктора обосновано лишь тогда, когда параметром передается переменная, содержащая строку. Либо когда он совсем маленький. За области - согласен, это удобно при доработке типовых (когда начинаются сложности с детализацией процедур), но областью обрамлять надо не скобки конструктора, а оператор Запрос.Текст = "..."; Причем еще удобно вставлять это дополнительно в конструкцию Если Истина Тогда ... КонецЕсли; - для перехода по хоткею ctrl + [, ctrl + ]. Т.е. в итоге будет так:

Запрос = Новый Запрос;
#Область ТекстЗапроса_СборДанныхПоТекущимОстаткам...

Если Истина Тогда
    Запрос.Текст = "...";
КонецЕсли;

#КонецОбласти
Показать
39. dj_serega 390 19.09.16 10:20 Сейчас в теме
(38) unichkin,
Причем еще удобно вставлять это дополнительно в конструкцию Если Истина Тогда ... КонецЕсли; - для перехода по хоткею ctrl + [, ctrl + ].

Для этого и существуют области. В настройках конфигуратора можно включить сворачивание областей.
Сори, но "Если Истина Тогда" - это по не знанию параметров конфигуратора :)
41. unichkin 1559 19.09.16 11:53 Сейчас в теме
(39) Действительно, сейчас проверил - работает хоткей по областям в 8.3.8. Я работал в какой-то версии, где перехода по областям не было - свертка была, а перехода по хоткею нет. Отсюда появилась "Если Истина Тогда", ну век живи - век учись, спасибо за науку. Тогда мой прошлый вброс снят с повестки дня :) Хотя все-равно использовать область в скобках конструктора - не есть хорошо, по моему мнению. Лучше областью обрамлять именно "Запрос.ТекстЗапроса = "";".
42. json 3297 19.09.16 12:13 Сейчас в теме
(41) unichkin, перемещаться по границам областей можно по таким же хоткеям. Только надо на решеточку спозиционироваться
5. ermek6 22 14.09.16 06:12 Сейчас в теме
Ну не знаю. Мне кажется что более удобен такой способ:

Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
ВременнаяТаблица = "ВЫБРАТЬ ....."
Запрос.Текс = ВременнаяТаблица;

Запрос.Выполнить();
ВременнаяТаблица = "ВременнаяТаблица";

Запрос.Текст = "ВЫБРАТЬ * ИЗ "+ВременнаяТаблица;

РЗ = Запрос.Выполнить();
Показать


Единственное. Я так понимаю, что доступа при отладке к содержимому Запрос.МенеджерВременныхТаблиц нет?
40. maxdmt 28 19.09.16 11:43 Сейчас в теме
(5) ermek6,


Единственное. Я так понимаю, что доступа при отладке к содержимому Запрос.МенеджерВременныхТаблиц нет?


Раньше просмотр делал так

Shift+F9
ВнешниеОбработки.Создать("E:\....\ВременнаяТаблица82.epf").ВременнаяТаблица(Запрос.МенеджерВременныхТаблиц, "ВашаВременнаяТаблица")
где в модуле обработки

Функция ВременнаяТаблица(МенеджерВрТаб, ИмяВТ) Экспорт
	Запрос = Новый Запрос;
	Запрос.Текст = "ВЫБРАТЬ ВрТаб.* ИЗ " + ИмяВТ + " КАК ВрТаб";
	Запрос.МенеджерВременныхТаблиц = МенеджерВрТаб;
	Возврат Запрос.Выполнить().Выгрузить();
КонецФункции




В 8.3.8 стало еще проще
Запрос.МенеджерВременныхТаблиц.Таблицы[0].ПолучитьДанные ().выгрузить()
6. vcv 89 14.09.16 06:27 Сейчас в теме
Еще помогает для читабельности делать по тексту запроса поиск с заменой. Особенно, если в нём активно используются повторяющиеся ВЫБОР КОГДА ИНАЧЕ ЕСЛИ. Эти конструкции сильно загромождают.
Правда конструктором такой запрос уже не откроешь.
7. nihfalck 14.09.16 09:48 Сейчас в теме
Плюсы.
1. понять, что происходит, можно не заглядывая в конструктор запроса
- можно понять что происходит просто глядя на правильно структурированный запрос. сначала по временным таблицам все выбрать и в конце сложить в единую выборку, например. при нормальном именовании временных таблиц - вполне читабельно. и не очень то понятно на самом деле "что происходит". не видно что именно выбирается - нужно лезть отдельно в каждую функцию.

2. текст каждого кусочка можно открывать конструктором запроса
- так себе плюс. можно весь запрос побитый на временные таблицы открыть. в конструкторе это даже удобней выглядит - весь запрос по закладочкам разложен. и зачем открывать отдельный кусочек? неудобно же вносить изменения - все поля вручную отслеживать... бррр...

3. легко добавлять комментарии, которые не удаляются конструктором запроса
- не поспоришь. хотя и не фанат комментариев внутри запроса - мне удобней перед общим запросом его описание со всеми временными таблицами написать 1 раз. но удобно, согласен

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

Минусы:
1. труднее поддерживать корректный состав полей между разными запросами
- колоссальный минус. начисто перечеркивает все плюсы. гигантская трудоемкость при внесении изменений в запрос. из недавнего - добавить в итоговой выборке вычисляемое поле. поля для вычисления - собираются с разных источников (в моем случае - временных таблиц). если запрос одним блоком идет - в конструкторе делов на 5 минут. вручную - повесишься пока протащишь через все соединения нужные поля.

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

y22-k; sh_max; RomanKrasin; uri1978; maljaev; Sam13; d_protos; Makushimo; madonov; meuses; artshun; Pasha1st; dj_serega; zqzq; sulfur17; DrAku1a; GorDAn; Uncore; Бубузяка; CyberCerber; ekaterinaeon; fvadim; Kozlopuper; SharlySka; +24 Ответить
9. json 3297 14.09.16 10:24 Сейчас в теме
(7) nihfalck, спасибо за развернутый комментарий.
Не соглашусь с некоторыми утверждениями
1. понять, что происходит, можно не заглядывая в конструктор запроса
- можно понять что происходит просто глядя на правильно структурированный запрос. сначала по временным таблицам все выбрать и в конце сложить в единую выборку, например. при нормальном именовании временных таблиц - вполне читабельно. и не очень то понятно на самом деле "что происходит". не видно что именно выбирается - нужно лезть отдельно в каждую функцию.

Если не видно что выбирается - значит плохое название функции. Вопрос к разработчику, а не к методике

2. текст каждого кусочка можно открывать конструктором запроса
- так себе плюс. можно весь запрос побитый на временные таблицы открыть. в конструкторе это даже удобней выглядит - весь запрос по закладочкам разложен. и зачем открывать отдельный кусочек? неудобно же вносить изменения - все поля вручную отслеживать... бррр...

Если временных таблиц хотя бы 20, то закладки с временными таблицами становятся нечитаемыми.
Если длинные имена таблиц (более двух слов), то их на закладках тоже читать неудобно.
При вашем подходе объединения (ОБЪЕДИНИТЬ ВСЕ) - никак не именуются, а это тоже неудобно

1. труднее поддерживать корректный состав полей между разными запросами
- колоссальный минус. начисто перечеркивает все плюсы. гигантская трудоемкость при внесении изменений в запрос. из недавнего - добавить в итоговой выборке вычисляемое поле. поля для вычисления - собираются с разных источников (в моем случае - временных таблиц). если запрос одним блоком идет - в конструкторе делов на 5 минут. вручную - повесишься пока протащишь через все соединения нужные поля.

Все зависит от качества кода. Если через таблицы протаскивать только НУЖНЫЕ поля, то их количество обычно мало и состав логичен и понятен.

В конечном счете вам решать, использовать или не использовать данный подход. Я лишь описал подход, который я применяю несколько месяцев и по моим ощущениям он сильно упростил [лично мне] жизнь. В новых типовых конфигурациях сейчас применяется именно он, а не описанный вами.
Vladimir Litvinenko; Tyler Durden; +2 Ответить
11. nihfalck 14.09.16 10:34 Сейчас в теме
(9)
про кучу ВТ в конструкторе согласен - у меня в одном из запросов их 30) имен не видно вообще, но навигация терпима все равно - порядок их следования спасает.

на счет подхода - почему нет? выбор реализации за разработчиком, в зависимости от задачи и необходимости внесения изменений в код в дальнейшем. и подход к структурированию кода в типовых - не эталон, а лишь вариант решения.
29. zqzq 23 15.09.16 11:07 Сейчас в теме
(11) nihfalck, а так же (9) yurii_host и др.: По поводу имен ВТ в конструкторе -- вы пробовали переходить на последнюю вкладку? Там простым списком и по щелчку открывается. Хоть 30 хоть 100 ВТ без проблем, а боковыми повёрнутыми закладками почти не пользуюсь.
Winstoncuk; +1 Ответить
30. json 3297 15.09.16 11:26 Сейчас в теме
(29) zqzq, честно говоря, не пробовал, т.к. пользуюсь конструктором очень редко. Всегда пишу запросы руками
Но спасибо за информацию, приму к сведению

Может еще добавите что-нибудь по поводу комментирования участков запроса или как удобно переключаться между объединениями в запросе, когда их много?
8. fvadim 9 14.09.16 10:20 Сейчас в теме
в сложных запросах уже давно использую конструктор только для проверки. поэтому пишу комментарии прям в запросе. получение текста запроса обычно вынесено в отдельную функцию.
10. json 3297 14.09.16 10:29 Сейчас в теме
(8) fvadim, тоже пишу запросы в основном руками и тоже использую конструктор в основном только для проверки.
Проблема в том, что когда работаешь в команде, то сталкиваешься с тем, что никто из участников команды больше так не умеет. И когда кто-то другой дорабатывал мои запросы - важные пояснения бывало, что сносили
sulfur17; +1 Ответить
12. json 3297 14.09.16 10:37 Сейчас в теме
Пока все покритиковавшие данный способ высказали свое мнение не попробовав его применить на практике.
Делаю вывод, что С ПЕРВОГО ВЗГЛЯДА его преимущества неочевидны.
Но намного интереснее было бы прочитать комментарий человека, который попытался его применить на практике. Такая оценка была бы более объективной
13. nihfalck 14.09.16 10:46 Сейчас в теме
(12) ну я возьму на вооружение. с теми же временными таблицами тоже не сразу стали понятны плюшки в свое время. в данный момент просто не на чем пробовать - другие задачи есть. а из того что навскидку нашел из задач со сложными запросами - умозрительно получилось вот так.
14. white-mount 14.09.16 12:11 Сейчас в теме
(12)
намного интереснее было бы прочитать комментарий человека, который попытался его применить на практике.

Аналогичный по смыслу метод использую давно, с начала поддержки 1с стандарта xml.
15. json 3297 14.09.16 14:23 Сейчас в теме
В своей практике подобный подход к написанию запросов я не встречал (только в типовых). Сделал предположение, что он малоизвестен, поэтому написал данную статью.
Но остается еще вероятность, что кто-нибудь применял такой прием (или работал с чужим кодом, где он применялся) и столкнулся с существенными проблемами.

Коллеги, может ли кто-нибудь отписаться о минусах из своей практики для большей полноты картины?
24. Synoecium 778 15.09.16 09:01 Сейчас в теме
(15) мне этот подход одно время тоже казался перспективным. Согласен почти со всеми описанными плюсами и минусами. Но, на практике результат этих плюсов и минусов нулевой и остается только возня по поддержанию этого механизма в рабочем состоянии. В общем, неплохой способ организации сложных запросов, но очень узкоприменимый, чтобы быть при этом полезным. Использовал я такой подход когда собирал запрос для формирования своих расчетных листков на базе конфигурации УПП 1.3. Текст запроса примерно такой:
ТекстЗапроса = 
	"ВЫБРАТЬ
	|	*
	|ПОМЕСТИТЬ втПостроитель
	|ИЗ
	|	&тзДанныеОСотрудниках КАК тзДанныеОСотрудниках"+
	";"+
	//ПолучитьТекстЗапросаНачислений()+
	//";"+
	ПолучитьТекстЗапросаСуммаНаРуки()+
	";"+
	ПолучитьТекстЗапросаФИОРаботников()+
	";"+
	ПолучитьТекстЗапросаНДФЛ()+
	";"+
	ПолучитьТекстЗапросаНДФЛГод()+
	";"
Показать
27. json 3297 15.09.16 09:42 Сейчас в теме
(24) Synoecium, спасибо, что отписались.
А вы в итоге перевели все на схему с одним запросом? Сейчас больше так не пишите?
31. Synoecium 778 15.09.16 11:52 Сейчас в теме
(27) запрос в расчетном листке так и оставил с разбивкой на функции, возвращающие блоки текста(в одной функции может быть несколько временных таблиц сразу) и больше нигде не использовал. Хорошо себя показал подход с использованием менеджера временных таблиц и разбивки текста запроса на несколько небольших запросов с вызовом метода Выполнить() после каждого. В принципе тоже самое можно сделать, просто склеив тексты запросов в один запрос перед выполнением, но тогда если таблицы уничтожаются в запросе, то их нельзя будет посмотреть отладчиком.
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц; 
Запрос.Текст = " ВЫБРАТЬ ...";
Запрос.Выполнить();
Запрос.Текст = "ВЫБРАТЬ ..."
Запрос.Выполнить();
...
Выборка = Запрос.Выполнить().Выбрать();
36. Sergey.Noskov 1376 17.09.16 13:48 Сейчас в теме
(15) красота идеи подкупает)
На практике приходилось сталкиваться, для себя отметил сложность отладки и доработки, что бы перенести запрос в консоль приходится либо запускать отладчик и на точке останова получать полный текст, либо бегать по функциям и собирать его по отдельности. Есть еще вариант получения текста выполнив часть кода в консоли кода (функции, при этом, должны быть экспортными), но с простотой открытия в конструкторе запроса это сложно сравнивать. Ну и обратная ситуация, после доработки, касающейся нескольких частей запроса, переносить это все обратно - то еще удовольствие.
Для себя определился в следующем: если части запроса будут использоваться по отдельности в разных процедурах/функциях, то ради отказа от дублирования кода есть смысл декомпозировать, а делать это только ради красоты - спорно.
16. 1cNike 209 14.09.16 17:29 Сейчас в теме
Встречал подобный подход и в бухе, на память в документе "Подтверждение нулевой ставки".
17. biimmap 1827 14.09.16 21:58 Сейчас в теме
слушай, а откуда у тебя первый пример кода??? там есть тэги //++ НЕ УТ... этого нет в тиражных решениях. тэги используются только внутренними разработчиками для определенных целей!

мне кажется эта статья пахнет нарушением авторских прав. (несмотря на раскрытие полезных приёмов)
19. json 3297 14.09.16 22:38 Сейчас в теме
(17) biimmap,
слушай, а откуда у тебя первый пример кода??? там есть тэги //++ НЕ УТ... этого нет в тиражных решениях. тэги используются только внутренними разработчиками для определенных целей!


я указал в статье источник
конфигурация ERP 2.1
Модуль ПартионныйУчет, фрагмент кода из функции ДанныеДляПартийТоваров()


Если посмотреть в УТ 11, то там этих тэгов не будет, т.к. в ней функционал урезан. Во время сборки он усекается по тэгам автоматизированно. Об этом описано в статьях на хабре
Я не стал их урезать, использовал как есть.

Но вообще ваше замечание справедливо, спасибо.
Я не собираюсь нарушать ничьи авторские права. В связи с этим я переделаю статью, убрав примеры из боевых конфигураций, заменив их на выдуманные (как обычно и делаю). Этого должно быть достаточно, т.к. согласно статье 1259 ГК п.5
Авторские права не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач, открытия, факты, языки программирования.
20. I_G_O_R 69 14.09.16 23:28 Сейчас в теме
(17) ха, похоже невнимательно работал в 1С)))
ERP вся напихана подобными комментариями, там еще встречается "НЕ УТКА"))
Winstoncuk; +1 Ответить
28. biimmap 1827 15.09.16 10:24 Сейчас в теме
(20) I_G_O_R, я запускал только версии рабочих хранилищ. там наличие тэгов норм. готовые релизы честно говоря ни разу не открывал. А так мой профиль ЗУП. я ни до работы в 1С с ЕРП не работал ни после. Поэтому и удивился тэгам в тексте.
18. biimmap 1827 14.09.16 22:01 Сейчас в теме
в целом код очень удобен. отлаживать элементарно! я работал в 1С 4 месяца.. кое-что в типовой релиз удалось вписать. как раз правил запросы, написанные в первом примере. Легко понимается, легко меняется, легко отлаживается. Сейчас вернулся на проект, документы, которые с нуля писал либо сам либо по моим ТЗ писали люди переделаю на этот подход проведение документа.
21. json 3297 15.09.16 00:33 Сейчас в теме
(18) biimmap, спасибо за отзыв.
Во время доработок типовых тоже не возникало никаких проблем с отладкой. Наоборот даже удобнее. После этого сделал несколько задач по такой схеме - понравилось. Остались еще несколько задач, которые подумываю перетащить на эту схему.

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

Но, возможно, я не замечаю минусы, т.к. практически обхожусь без конструктора запросов. А большинство разработчиков с которыми я сталкивался, вообще никогда не пишут без него. Даже несмотря на все минусы конструктора такие как: неудобство писать подзапросы в условиях ГДЕ, непредсказуемое поведение при переименовании поля и др.
А возможно дело не в конструкторе, а в том, что нужно попробовать прежде, чем делать выводы.

Но никому ничего навязывать я не собираюсь. Каждый сам за себя решает.
22. DrAku1a 1679 15.09.16 03:25 Сейчас в теме
Просмотреть структуру большого запроса - Отладчик запросов -> Визуальная структура запросов.
Там для пакетного запроса выводятся имена временных таблиц.
23. json 3297 15.09.16 08:39 Сейчас в теме
(22) DrAku1a, реклама не в тему. Обсуждение идет про написание запросов, а не про отладку
25. palsergeich 15.09.16 09:13 Сейчас в теме
Унифицированность - это хорошо. Один и тот же кусок кода можно использовать много где.
Но чем универсальнее механизм, тем сложнее его поддерживать....
Неудобство писать подзапросы в условиях ГДЕ - в чем проблема снять галочку и нажать три точки, да надо выделить один пробел нажать ПКМ и вызовется конструктор, иначе он не вызывается. Другой вопрос, оптимально ли это, как показала практика внутреннее соединение отрабатывает быстрее условия в подзапросе....
32. Vortigaunt 96 15.09.16 12:17 Сейчас в теме
Я похожий подход использую, когда пишу прямые запросы к SQL. Только я не использую функции, а пишу текст подзапроса, присваиваю его переменной. Затем пишу текст внешнего запроса, а переменную вставляю в скобочки в предложение FROM.
Мне такой метод помогает составить и отладить большие запросы. Каждый отдельный кусочек можно выполнить и посмотреть, что возвращает. Достаточно в методе RS.Execute() в параметре поменять переменную, которая возвращает текст запроса.
Для 1с 8 стараюсь использовать по максумуму возможности конструктора запросов. Пусть даже он будет километровой простыней. Главное, чтобы открывался в конструкторе.
35. tormozit 7136 17.09.16 10:36 Сейчас в теме
Комментарии сохраняет собственный конструктор запроса из подсистемы "Инструменты разработчика". https://www.youtube.com/watch?v=oQoW-N_0xac . Также он поддерживает именованные обращения к результатам пакетного запроса.
37. tormozit 7136 18.09.16 09:20 Сейчас в теме
Я придерживаюсь методики соблюдения синтаксической корректности по возможности всех фрагментов текстов запроса. Это позволяет их редактировать в любом конструкторе запроса и использовать дерево запроса. Повторяющиеся/динамические формируемые части запроса можно оформлять в виде временных таблиц. В 8.3.7 уже можно без сложных вспомогательных методов использовать заглушки подзапросов (например ВЫБРАТЬ ЗНАЧЕНИЕ(Справочник.Сотрудники.ПустаяСсылка) КАК Сотрудник, 0 КАК Оклад, "" КАК ФИО ГДЕ 0="<ИдентификаторЗаглушки>"), которые затем заменять на идентичные по составу полей подзапросы.
Бывалый77; +1 Ответить
43. I_G_O_R 69 01.10.16 23:27 Сейчас в теме
Лично сам напоролся на вот такой косяк, когда смотришь запросы по отдельности, то считаешь, что получится один результат, а в результате получается другой:
ТекстЗапроса1 = "
|ВЫБРАТЬ
|	1 КАК Поле1,
|	2 КАК Поле2
|";

ТекстЗапроса2 = "
|ВЫБРАТЬ
|	2 КАК Поле2,
|	1 КАК Поле1
|";

ИтоговыйТекстЗапроса = ТекстЗапроса1 
+ "ОБЪЕДИНИТЬ ВСЕ" + ТекстЗапроса2;
Показать

Получается, что я в лагере тех, кому этот способ скорее не нравится, чем нравится.
Gilev.Vyacheslav; +1 Ответить
44. AlX0id 01.11.16 09:26 Сейчас в теме
Стесняюсь спросить - про сехмы запросов еще не упоминали? ) Казалось бы они были созданы как раз для подобных задач )
45. vec435 15 03.11.16 13:20 Сейчас в теме
короче, как ни крути отсутствие в 1с объекта "запрос" с хранимыми параметрами, текстом, МВТ - один бооольшой минус. (как например в любой СУБД) .
46. Drizer2000 14 03.11.16 16:10 Сейчас в теме
В комментариях читаю, что некоторые пользуются без конструктора запросов - для меня это уже какое-то извращение -это тоже самое, что большую яму копать маленьким савочком, а не лопатой или экскаватором. Объяснитесь хоть, это типа так круто?. Я все запросы делаю через консоль запросов, тут же их отлаживаю, а потом генерирую готовый код и вставляю в рабочий модуль.
47. корум 287 03.11.16 16:22 Сейчас в теме
(46) текст запроса может быть сохранен где-то отдельно, и в данную базу вставляется и допиливается на месте.
Тыркать мышкой в конструкторе в этом случае менее эффективно, чем переписать пару мест в запросе, и лишь потом открывать конструктор.
48. DenisCh 03.11.16 16:27 Сейчас в теме
(46) Пользоваться консолью запросов и конструктором запросов - это такая же разница, как между занятием любовью с любимой женщиной и левой рукой.
49. Drizer2000 14 03.11.16 21:56 Сейчас в теме
(48) DenisCh, когда говорят о конструкторе запроса, я все-таки подразумеваю консоль.т.к. в консоле есть и конструктор,типовым конструктором никогда не пользуюсь. Речь все-таки идет о полностью ручном написании запросов, в чем интерес так писать запросы, а потом еще гордится,что большинство так не умеют.
50. json 3297 04.11.16 19:12 Сейчас в теме
(46) Drizer2000, (49) Drizer2000,

Проголосовал за ваш комментарий, не потому что согласен с вашей точкой зрения, а потому что задали хороший вопрос

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

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

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

Лично я активно использовал конструктор, когда только начинал программировать, но т.к. мы поддерживали параллельно и 7-ку и 8-ку, то пришлось освоить t-sql, в котором слезы, а не конструктор запросов. Привыкнув к несложному синтаксису sql, я понял, что использование конструктора в 8-ке имеет ряд очень существенных неудобств, проще писать сразу текст. Самым большим неудобством в написании текста запроса прямо в коде является подстановка "палочек" в начало строки. Это просто огромное неудобство, но оно решилось с появлением телепата в 7-ке и снегопата в 8-ке.

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

Теперь про неудобства конструктора.
1. Выбираемое поле и его синоним располагаются на разных закладках!!!
Запомнить соответствие практически нереально, при работе со сложными запросами (в которых большое количество полей). Гораздо проще прочитать в коде вот такое: тч.Номенклатура КАК Ингредиент, независимо от того, сколько полей в выборке, чем сопоставлять искать глазами по списку полей, отсчитывая сверху.
2. Таблицы и условия связи на разных закладках. Тоже очень неудобно приходится хранить в голове еще и эту информацию при переключении между вкладками.
3. Не видно какая таблица является источником данных, если для нее задан синоним. Опять нужно тыркать мышкой и запоминать (так, оперативная память в голове уже закончилась на предыдущих пунктах)
4. Неудобно читать сложные условия при соединении таблиц или в секции ГДЕ. Опять нужно переключить закладку, тыркнуть мышкой и запомнить.
5. Нельзя добавить комментарий. Это разве не является неудобством?
6. Когда пишешь кодом, можно применять форматирование, например, сделать несколько дополнительных отступов, чтобы быстро находить глазами ту часть, над которой работаешь в текущий момент. При работе с конструктором все свои изменения нужно запоминать
7. Непредсказуемое поведение. Вы захотели немного изменить выбираемое поле, чтобы Номенклатура бралось из табличной части, а не из регистра, как это было до этого. Одно неосторожное движение, и оно может удалиться везде дальше по коду, где оно упомянуто.
8. Нельзя отменить только последнее действие, можно только вернуться к тому запросу, который был до открытия конструктора. Попадали в ситуацию, когда выполнили ряд изменений и вдруг случайно удалили не то поле, которое хотели? Только честно.
На этом прервусь, хотя этот список можно было бы и продолжить.

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

Можете заглянуть в запросы в типовых конфигурациях, например, в ерпи, например, в модуле ПартионныйУчет. В них код отформатирован вручную. Разработчики типовых часто пишут сложные запросы руками.

Я никого не пытаюсь убедить, в том нужно ли использовать конструктор или не нужно. Каждый работает так, как ему удобнее, или скорее ПРИВЫЧНЕЕ. При этом мы готовы мириться с недостатками привычных нам инструментов и с какого-то момента перестаем их замечать.

Лично мое мнение такое, что "эксковатором", если использовать вашу же метафору является язык запросов. И если вы не умеете управлять эксковатором, то будете пользоваться "лопатой", потому что так привычнее для вас.
Я бы предложил более подходящую на мой взгляд метафору: конструктор можно сравнить с автоматической коробкой передач, а язык запросов - с механической. Первой проще научиться управлять, но вторая более надежная и предоставляет больше возможностей.
amiralnar; fvadim; r.zdorkin; Diplomat000; корум; +5 Ответить
Оставьте свое сообщение