gifts2017

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

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

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

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

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


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

Пример 1

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

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

Пример 2

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

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

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

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

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

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

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

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

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

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

Минусы:

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

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

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Николай Васильев (vasilev2015) 13.09.16 09:32
В ЗУП запросы разбивают по временным таблицам, значения которых передают Менеджером Временных Таблиц. Тоже вариант.
2. white mount (white-mount) 13.09.16 09:38
Плюсы такого подхода:

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

Сам справочник своих "стандартных функций" удобнее хранить в нотации xml, для автоматизации построения запросов.
3. Роман Уничкин (unichkin) 13.09.16 09:58
Еще удобно выносить текст запроса в отдельную функцию, возвращающую строку. Т.е. не писать

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

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


а вот так:

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

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

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

...Показать Скрыть
Denis S; Bazin; sulfur17; +3 Ответить 2
4. Пишу код как картины (yurii_host) 13.09.16 10:44
(1) vasilev2015, согласен, что такой подход решает проблему с понимаемостью запроса, но возникают трудности с отладкой. Если нужно отладить очередной запрос, который использует несколько временных таблиц, которые пришли через МВТ, то не получится так просто открыть консоль запроса в точке останова, т. к. в нее можно передать запрос с параметрами, но без временных таблиц.

(3) unichkin, имхо, удобнее, когда функция содержит не весь текст запроса, а только часть запроса, которую можно отдельно открыть конструктором. В этом случае с ним проще работать, т.к. можно быстрее перейти к нужному участку запроса, а также в самой этой функции можно добавлять комментарии, что тоже немаловажно в сложных запросах
5. Yermek Zhubatyrov (ermek6) 14.09.16 06:12
Ну не знаю. Мне кажется что более удобен такой способ:

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

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

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

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


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

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

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

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

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

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

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; +23 Ответить 1
8. vadim vadim (fvadim) 14.09.16 10:20
в сложных запросах уже давно использую конструктор только для проверки. поэтому пишу комментарии прям в запросе. получение текста запроса обычно вынесено в отдельную функцию.
9. Пишу код как картины (yurii_host) 14.09.16 10:24
(7) nihfalck, спасибо за развернутый комментарий.
Не соглашусь с некоторыми утверждениями
1. понять, что происходит, можно не заглядывая в конструктор запроса
- можно понять что происходит просто глядя на правильно структурированный запрос. сначала по временным таблицам все выбрать и в конце сложить в единую выборку, например. при нормальном именовании временных таблиц - вполне читабельно. и не очень то понятно на самом деле "что происходит". не видно что именно выбирается - нужно лезть отдельно в каждую функцию.

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

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

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

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

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

В конечном счете вам решать, использовать или не использовать данный подход. Я лишь описал подход, который я применяю несколько месяцев и по моим ощущениям он сильно упростил [лично мне] жизнь. В новых типовых конфигурациях сейчас применяется именно он, а не описанный вами.
VladimirL; Tyler Durden; +2 Ответить 1
10. Пишу код как картины (yurii_host) 14.09.16 10:29
(8) fvadim, тоже пишу запросы в основном руками и тоже использую конструктор в основном только для проверки.
Проблема в том, что когда работаешь в команде, то сталкиваешься с тем, что никто из участников команды больше так не умеет. И когда кто-то другой дорабатывал мои запросы - важные пояснения бывало, что сносили
sulfur17; +1 Ответить
11. Андрей Моисеев (nihfalck) 14.09.16 10:34
(9) yurii_host,
про кучу ВТ в конструкторе согласен - у меня в одном из запросов их 30) имен не видно вообще, но навигация терпима все равно - порядок их следования спасает.

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

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

Коллеги, может ли кто-нибудь отписаться о минусах из своей практики для большей полноты картины?
16. Вавилов Николай Vavilov (1cNike) 14.09.16 17:29
Встречал подобный подход и в бухе, на память в документе "Подтверждение нулевой ставки".
17. biimmap Филатов (biimmap) 14.09.16 21:58
слушай, а откуда у тебя первый пример кода??? там есть тэги //++ НЕ УТ... этого нет в тиражных решениях. тэги используются только внутренними разработчиками для определенных целей!

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


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


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

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

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

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

Но никому ничего навязывать я не собираюсь. Каждый сам за себя решает.
22. Андрей Акулов (DrAku1a) 15.09.16 03:25
Просмотреть структуру большого запроса - Отладчик запросов -> Визуальная структура запросов.
Там для пакетного запроса выводятся имена временных таблиц.
23. Пишу код как картины (yurii_host) 15.09.16 08:39
(22) DrAku1a, реклама не в тему. Обсуждение идет про написание запросов, а не про отладку
24. Сергей Лесовой (Synoecium) 15.09.16 09:01
(15) yurii_host, мне этот подход одно время тоже казался перспективным. Согласен почти со всеми описанными плюсами и минусами. Но, на практике результат этих плюсов и минусов нулевой и остается только возня по поддержанию этого механизма в рабочем состоянии. В общем, неплохой способ организации сложных запросов, но очень узкоприменимый, чтобы быть при этом полезным. Использовал я такой подход когда собирал запрос для формирования своих расчетных листков на базе конфигурации УПП 1.3. Текст запроса примерно такой:
ТекстЗапроса = 
	"ВЫБРАТЬ
	|	*
	|ПОМЕСТИТЬ втПостроитель
	|ИЗ
	|	&тзДанныеОСотрудниках КАК тзДанныеОСотрудниках"+
	";"+
	//ПолучитьТекстЗапросаНачислений()+
	//";"+
	ПолучитьТекстЗапросаСуммаНаРуки()+
	";"+
	ПолучитьТекстЗапросаФИОРаботников()+
	";"+
	ПолучитьТекстЗапросаНДФЛ()+
	";"+
	ПолучитьТекстЗапросаНДФЛГод()+
	";"
...Показать Скрыть
25. Павел Жихарев (palsergeich) 15.09.16 09:13
Унифицированность - это хорошо. Один и тот же кусок кода можно использовать много где.
Но чем универсальнее механизм, тем сложнее его поддерживать....
Неудобство писать подзапросы в условиях ГДЕ - в чем проблема снять галочку и нажать три точки, да надо выделить один пробел нажать ПКМ и вызовется конструктор, иначе он не вызывается. Другой вопрос, оптимально ли это, как показала практика внутреннее соединение отрабатывает быстрее условия в подзапросе....
26. Николай Орлов (sulfur17) 15.09.16 09:18
(2) white-mount, можно вас попросить, расшифруйте пожалуйста о чем речь?
Давно работаю с 1С, но совершенно не понял о чем вы.
Это я о каких-то технологиях не знаю?
27. Пишу код как картины (yurii_host) 15.09.16 09:42
(24) Synoecium, спасибо, что отписались.
А вы в итоге перевели все на схему с одним запросом? Сейчас больше так не пишите?
28. biimmap Филатов (biimmap) 15.09.16 10:24
(20) I_G_O_R, я запускал только версии рабочих хранилищ. там наличие тэгов норм. готовые релизы честно говоря ни разу не открывал. А так мой профиль ЗУП. я ни до работы в 1С с ЕРП не работал ни после. Поэтому и удивился тэгам в тексте.
29. ффф ыыы (zqzq) 15.09.16 11:07
(11) nihfalck, а так же (9) yurii_host и др.: По поводу имен ВТ в конструкторе -- вы пробовали переходить на последнюю вкладку? Там простым списком и по щелчку открывается. Хоть 30 хоть 100 ВТ без проблем, а боковыми повёрнутыми закладками почти не пользуюсь.
Winstoncuk; +1 Ответить 1
30. Пишу код как картины (yurii_host) 15.09.16 11:26
(29) zqzq, честно говоря, не пробовал, т.к. пользуюсь конструктором очень редко. Всегда пишу запросы руками
Но спасибо за информацию, приму к сведению

Может еще добавите что-нибудь по поводу комментирования участков запроса или как удобно переключаться между объединениями в запросе, когда их много?
31. Сергей Лесовой (Synoecium) 15.09.16 11:52
(27) yurii_host, запрос в расчетном листке так и оставил с разбивкой на функции, возвращающие блоки текста(в одной функции может быть несколько временных таблиц сразу) и больше нигде не использовал. Хорошо себя показал подход с использованием менеджера временных таблиц и разбивки текста запроса на несколько небольших запросов с вызовом метода Выполнить() после каждого. В принципе тоже самое можно сделать, просто склеив тексты запросов в один запрос перед выполнением, но тогда если таблицы уничтожаются в запросе, то их нельзя будет посмотреть отладчиком.
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц; 
Запрос.Текст = " ВЫБРАТЬ ...";
Запрос.Выполнить();
Запрос.Текст = "ВЫБРАТЬ ..."
Запрос.Выполнить();
...
Выборка = Запрос.Выполнить().Выбрать();
...Показать Скрыть
32. Дмитрий Касминюк (Vortigaunt) 15.09.16 12:17
Я похожий подход использую, когда пишу прямые запросы к SQL. Только я не использую функции, а пишу текст подзапроса, присваиваю его переменной. Затем пишу текст внешнего запроса, а переменную вставляю в скобочки в предложение FROM.
Мне такой метод помогает составить и отладить большие запросы. Каждый отдельный кусочек можно выполнить и посмотреть, что возвращает. Достаточно в методе RS.Execute() в параметре поменять переменную, которая возвращает текст запроса.
Для 1с 8 стараюсь использовать по максумуму возможности конструктора запросов. Пусть даже он будет километровой простыней. Главное, чтобы открывался в конструкторе.
33. white mount (white-mount) 15.09.16 12:29
(26) sulfur17,
"white-mount, можно вас попросить, расшифруйте пожалуйста о чем речь?
Давно работаю с 1С, но совершенно не понял о чем вы.
Это я о каких-то технологиях не знаю?"

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

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

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

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

Метод модульности позволяет легко визуализировать конструкцию запроса, используя графы.
Что в свою очередь упрощает конструирование или оптимизацию исходных объектов - документов, справочников, регистров и их реквизитов.
34. Сергей Галюк (dj_serega) 15.09.16 15:56
(3) unichkin, Я в 8.3 юзаю области.
Шаблон:
Запрос<?"Имя переменной запроса:"> = Новый Запрос(
#Область Текст_запроса
"<?"", ТекстЗапроса>"
#КонецОбласти
);
<?>Запрос<?"Имя переменной запроса:">.УстановитьПараметр("", );

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

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

РезультатПримерЗапросаВыполнить = ЗапросПримерЗапроса.Выполнить();
РезультатПримерЗапроса = РезультатПримерЗапросаВыполнить.Выбрать();
РезультатПримерЗапроса = РезультатПримерЗапросаВыполнить.Выгрузить();
...Показать Скрыть
35. Сергей Старых (tormozit) 17.09.16 10:36
Комментарии сохраняет собственный конструктор запроса из подсистемы "Инструменты разработчика". https://www.youtube.com/watch?v=oQoW-N_0xac . Также он поддерживает именованные обращения к результатам пакетного запроса.
36. Сергей Носков (Sergey.Noskov) 17.09.16 13:48
(15) yurii_host, красота идеи подкупает)
На практике приходилось сталкиваться, для себя отметил сложность отладки и доработки, что бы перенести запрос в консоль приходится либо запускать отладчик и на точке останова получать полный текст, либо бегать по функциям и собирать его по отдельности. Есть еще вариант получения текста выполнив часть кода в консоли кода (функции, при этом, должны быть экспортными), но с простотой открытия в конструкторе запроса это сложно сравнивать. Ну и обратная ситуация, после доработки, касающейся нескольких частей запроса, переносить это все обратно - то еще удовольствие.
Для себя определился в следующем: если части запроса будут использоваться по отдельности в разных процедурах/функциях, то ради отказа от дублирования кода есть смысл декомпозировать, а делать это только ради красоты - спорно.
37. Сергей Старых (tormozit) 18.09.16 09:20
Я придерживаюсь методики соблюдения синтаксической корректности по возможности всех фрагментов текстов запроса. Это позволяет их редактировать в любом конструкторе запроса и использовать дерево запроса. Повторяющиеся/динамические формируемые части запроса можно оформлять в виде временных таблиц. В 8.3.7 уже можно без сложных вспомогательных методов использовать заглушки подзапросов (например ВЫБРАТЬ ЗНАЧЕНИЕ(Справочник.Сотрудники.ПустаяСсылка) КАК Сотрудник, 0 КАК Оклад, "" КАК ФИО ГДЕ 0="<ИдентификаторЗаглушки>"), которые затем заменять на идентичные по составу полей подзапросы.
Бывалый77; +1 Ответить
38. Роман Уничкин (unichkin) 18.09.16 23:16
(34) dj_serega, мне кажется создание объекта запроса с параметром конструктора обосновано лишь тогда, когда параметром передается переменная, содержащая строку. Либо когда он совсем маленький. За области - согласен, это удобно при доработке типовых (когда начинаются сложности с детализацией процедур), но областью обрамлять надо не скобки конструктора, а оператор Запрос.Текст = "..."; Причем еще удобно вставлять это дополнительно в конструкцию Если Истина Тогда ... КонецЕсли; - для перехода по хоткею ctrl + [, ctrl + ]. Т.е. в итоге будет так:

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

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

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

Для этого и существуют области. В настройках конфигуратора можно включить сворачивание областей.
Сори, но "Если Истина Тогда" - это по не знанию параметров конфигуратора :)
40. maxdmt (maxdmt) 19.09.16 11:43
(5) ermek6,


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


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

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

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




В 8.3.8 стало еще проще
Запрос.МенеджерВременныхТаблиц.Таблицы[0].ПолучитьДанные ().выгрузить()
41. Роман Уничкин (unichkin) 19.09.16 11:53
(39) Действительно, сейчас проверил - работает хоткей по областям в 8.3.8. Я работал в какой-то версии, где перехода по областям не было - свертка была, а перехода по хоткею нет. Отсюда появилась "Если Истина Тогда", ну век живи - век учись, спасибо за науку. Тогда мой прошлый вброс снят с повестки дня :) Хотя все-равно использовать область в скобках конструктора - не есть хорошо, по моему мнению. Лучше областью обрамлять именно "Запрос.ТекстЗапроса = "";".
42. Пишу код как картины (yurii_host) 19.09.16 12:13
(41) unichkin, перемещаться по границам областей можно по таким же хоткеям. Только надо на решеточку спозиционироваться
43. Игорь <...> (I_G_O_R) 01.10.16 23:27
Лично сам напоролся на вот такой косяк, когда смотришь запросы по отдельности, то считаешь, что получится один результат, а в результате получается другой:
ТекстЗапроса1 = "
|ВЫБРАТЬ
|	1 КАК Поле1,
|	2 КАК Поле2
|";

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

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

Получается, что я в лагере тех, кому этот способ скорее не нравится, чем нравится.
Gilev.Vyacheslav; +1 Ответить
44. Алексей 1 (AlX0id) 01.11.16 09:26
Стесняюсь спросить - про сехмы запросов еще не упоминали? ) Казалось бы они были созданы как раз для подобных задач )
45. Владимир Чаклин (vec435) 03.11.16 13:20
короче, как ни крути отсутствие в 1с объекта "запрос" с хранимыми параметрами, текстом, МВТ - один бооольшой минус. (как например в любой СУБД) .
46. Алексей Станиславович (Drizer2000) 03.11.16 16:10
В комментариях читаю, что некоторые пользуются без конструктора запросов - для меня это уже какое-то извращение -это тоже самое, что большую яму копать маленьким савочком, а не лопатой или экскаватором. Объяснитесь хоть, это типа так круто?. Я все запросы делаю через консоль запросов, тут же их отлаживаю, а потом генерирую готовый код и вставляю в рабочий модуль.
yurii_host; +1 Ответить 3
47. rjhev korum (корум) 03.11.16 16:22
(46) текст запроса может быть сохранен где-то отдельно, и в данную базу вставляется и допиливается на месте.
Тыркать мышкой в конструкторе в этом случае менее эффективно, чем переписать пару мест в запросе, и лишь потом открывать конструктор.
48. DenisCh Гейтс (DenisCh) 03.11.16 16:27
(46) Пользоваться консолью запросов и конструктором запросов - это такая же разница, как между занятием любовью с любимой женщиной и левой рукой.
49. Алексей Станиславович (Drizer2000) 03.11.16 21:56
(48) DenisCh, когда говорят о конструкторе запроса, я все-таки подразумеваю консоль.т.к. в консоле есть и конструктор,типовым конструктором никогда не пользуюсь. Речь все-таки идет о полностью ручном написании запросов, в чем интерес так писать запросы, а потом еще гордится,что большинство так не умеют.
50. Пишу код как картины (yurii_host) 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. Нельзя отменить только последнее действие, можно только вернуться к тому запросу, который был до открытия конструктора. Попадали в ситуацию, когда выполнили ряд изменений и вдруг случайно удалили не то поле, которое хотели? Только честно.
На этом прервусь, хотя этот список можно было бы и продолжить.

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

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

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

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