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

(1) vasilev2015, согласен, что такой подход решает проблему с понимаемостью запроса, но возникают трудности с отладкой. Если нужно отладить очередной запрос, который использует несколько временных таблиц, которые пришли через МВТ, то не получится так просто открыть консоль запроса в точке останова, т. к. в нее можно передать запрос с параметрами, но без временных таблиц.

(3) unichkin, имхо, удобнее, когда функция содержит не весь текст запроса, а только часть запроса, которую можно отдельно открыть конструктором. В этом случае с ним проще работать, т.к. можно быстрее перейти к нужному участку запроса, а также в самой этой функции можно добавлять комментарии, что тоже немаловажно в сложных запросах

(2) white-mount, можно вас попросить, расшифруйте пожалуйста о чем речь?
Давно работаю с 1С, но совершенно не понял о чем вы.
Это я о каких-то технологиях не знаю?

(3) unichkin, Я в 8.3 юзаю области.
Шаблон:

Результат:

(5) ermek6,



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

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





В 8.3.8 стало еще проще
Запрос.МенеджерВременныхТаблиц.Таблицы[0].ПолучитьДанные ().выгрузить()

(7) nihfalck, спасибо за развернутый комментарий.
Не соглашусь с некоторыми утверждениями

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


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


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

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

(8) fvadim, тоже пишу запросы в основном руками и тоже использую конструктор в основном только для проверки.
Проблема в том, что когда работаешь в команде, то сталкиваешься с тем, что никто из участников команды больше так не умеет. И когда кто-то другой дорабатывал мои запросы - важные пояснения бывало, что сносили

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

(12)

Аналогичный по смыслу метод использую давно, с начала поддержки 1с стандарта xml.

(15) мне этот подход одно время тоже казался перспективным. Согласен почти со всеми описанными плюсами и минусами. Но, на практике результат этих плюсов и минусов нулевой и остается только возня по поддержанию этого механизма в рабочем состоянии. В общем, неплохой способ организации сложных запросов, но очень узкоприменимый, чтобы быть при этом полезным. Использовал я такой подход когда собирал запрос для формирования своих расчетных листков на базе конфигурации УПП 1.3. Текст запроса примерно такой:

(15) красота идеи подкупает)
На практике приходилось сталкиваться, для себя отметил сложность отладки и доработки, что бы перенести запрос в консоль приходится либо запускать отладчик и на точке останова получать полный текст, либо бегать по функциям и собирать его по отдельности. Есть еще вариант получения текста выполнив часть кода в консоли кода (функции, при этом, должны быть экспортными), но с простотой открытия в конструкторе запроса это сложно сравнивать. Ну и обратная ситуация, после доработки, касающейся нескольких частей запроса, переносить это все обратно - то еще удовольствие.
Для себя определился в следующем: если части запроса будут использоваться по отдельности в разных процедурах/функциях, то ради отказа от дублирования кода есть смысл декомпозировать, а делать это только ради красоты - спорно.

(17) biimmap,


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

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

Но вообще ваше замечание справедливо, спасибо.
Я не собираюсь нарушать ничьи авторские права. В связи с этим я переделаю статью, убрав примеры из боевых конфигураций, заменив их на выдуманные (как обычно и делаю). Этого должно быть достаточно, т.к. согласно статье 1259 ГК п.5
Авторские права не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач, открытия, факты, языки программирования.

(17) ха, похоже невнимательно работал в 1С)))
ERP вся напихана подобными комментариями, там еще встречается "НЕ УТКА"))

(18) biimmap, спасибо за отзыв.
Во время доработок типовых тоже не возникало никаких проблем с отладкой. Наоборот даже удобнее. После этого сделал несколько задач по такой схеме - понравилось. Остались еще несколько задач, которые подумываю перетащить на эту схему.

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

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

Но никому ничего навязывать я не собираюсь. Каждый сам за себя решает.

(22) DrAku1a, реклама не в тему. Обсуждение идет про написание запросов, а не про отладку

(46) текст запроса может быть сохранен где-то отдельно, и в данную базу вставляется и допиливается на месте.
Тыркать мышкой в конструкторе в этом случае менее эффективно, чем переписать пару мест в запросе, и лишь потом открывать конструктор.

(46) Пользоваться консолью запросов и конструктором запросов - это такая же разница, как между занятием любовью с любимой женщиной и левой рукой.

(46) Drizer2000, (49) Drizer2000,

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

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

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

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

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

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

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

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

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

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

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