В чем смысл расширения языка запросов для СКД? #508853

В конструкторе запроса на закладке "Компоновка данных" можно указать поля для выбора пользователей в запрос. Причем эти поля можно выбирать только из уже выбранных полей на закладке "Таблицы и поля". Получается какое-то задвоение.... Причем сгенерированный запрос действительно эти поля содержит дважды: первый раз без фигурных скобок, а второй раз- с ними. В 8.1 Построитель отчета использовал подобные расширения, чтобы не выбирать лишних данных и поля указывались в тексте запроса только один раз в фигурных скобках. В чем смысл?

Такой же смысл как и в построителе

а почем записывается дважды?

"Потом" чтобы знать как скомпоновать запрос выполнения при заданных настройках пользователя.

Потому что есть волшебная кнопочка "Автозаполнение".

А что построитель отчета не мог скомпоновать без лишнего текста? а причем тут автозаполнение? Указывать свойства полей необходимо в любом случае (даже если они используются не всегда)

Если ты не будешь использовать директивы компоновки твой запрос будет выполнятся в полном "оригинальном" виде при любых настройках пользователя.

Это понятно. Вопрос в другом: зачем дублировать текст запроса? Ведь в построителе отчета такого не было.

Было

может это ошибка? Ведь она дает выбирать только из полей, которые уже выбраны. А должна давать выбирать из всех полей таблиц указанных на закладке "Таблицы" закладки "Компановка данных"...

не было. Там поля перечислялись один раз (или в фигурных скобках или без).

Под полный "дублированием запроса", если я тебя понял,  подразумевается исключение выборки вложенной таблицы, в случае если ее поля не используются. Смотри в конструкторе запроса на закладке компоновки данный подзакладку таблицы и в ней обрати внимание на признак "обязательности".

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

Да нет, же. Почему сгенерированный текст запроса содержит оба поля: Валюта {Валюта} Ведь надо только (так было в построителе отчета): {Валюта}

Потому что ты задал псевдоним поля.

Так ведь система компоновки и должна этим заниматься (с учетом настроек пользователя формировать обращение к БД). Зачем еще какие-то дополнительные настройки? В 1с создал справочник с двумя реквизитами и создал Отчет. Его Основная схема компановки данных содержит набор данных "запрос": SELECT    Catalog1.Attribute1,    Catalog1.Attribute2 AS Attribute2 {SELECT    Attribute2} FROM    Catalog.Catalog1 AS Catalog1 (То есть второй реквизит справочника добавлен в поля на закладке "компановка данных" построителя запроса, а первый- не добавлен). Открываю 1с и Profiler и строю отчеты: 1. Вывести детальные записи с обоими реквизитами: SELECT T1._Fld8, T1._Fld9 FROM _Reference7 T1 WITH(NOLOCK) 2. Вывести детальные записи ТОЛЬКО с полем 1: SELECT T1._Fld8 FROM _Reference7 T1 WITH(NOLOCK) 3. Вывести детальные записи ТОЛЬКО с полем 2: SELECT T1._Fld9 FROM _Reference7 T1 WITH(NOLOCK) Видно, что никаких лишних полей в запрос не попадает. Поэтому вопрос остается в силе: В чем смысл расширения языка запросов для СКД?

А! Вот видите, молчите! Тоже задумались зачем эта фигня сбоку прикручена!

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

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

что такое "директивами условной выборки на верхнем и вложенном уровне запроса"? И что такое "Заверни этот же запрос во вложенный"?

а эта информация откуда? (где можно почитать?)

Действительно на закладке "Компановка данных", "Таблицы" конструктора запроса есть колонка "Номер группы", но единственное на что она влияет- возможность объединенения / разъединения обращения к таблицам. То есть, если номер группы одинаковый и вы обращаетесь к одной из таблиц, то автоматически будет произведено объединение основной таблицы со всеми таблицами ее группы.

1) Другими словами поля выборки в фигурных скобках 2) Вложенный запрос - Где почитать - не подскажу. Вот примеры запросов для эсперементов с настройками. Попробуй поиграться настройками и посмотреть на финальные запросы. Кстати - для схемы финальный запрос проще вытаскивать из собранного макета, чем ловить в профайлере    ИЗ        РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних) КАК ВложенныйЗапрос

"но единственное на что она влияет- возможность объединенения / разъединения обращения к таблицам." ___________ Т.е. возможность отрезать часть вложенных запросов при ненадобности - это так мало ?

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

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

Не следует путать опциальность присоединения целых таблиц и опциональную выборку конкретных полей таблицы.

Кстати, по этому вопросу, похоже, вообще нет ничего в литературе. И никакой документации. Т.е., 1С придумала что-то, а все остальные должны догадываться, для чего это нужно...

Поигрался и вывод такой: опциональные поля имеет смысл использовать ТОЛЬКО во вложенных запросах (в этом случае с их помощью во вложенном запросе можно сократить количество выбираемых полей). То есть использование опциональных полей на самом верхнем уровне запроса- бессмысленное стесывание пальцев об клавиатуру. не путаю я только на диске ИТС в документации нашел сухую справку, что дескать вот так можно написать. Но ни для чего, ни последствий- ничего нет. (Хорошо я в свое время работал с 8.0. Поэтому знаю для чего фигурные скобки используют и, простите за выражение, произвел аналитическое продолжение фигурных скобок.

Поля запроса могут либо использоваться в соединениях, либо в качестве полей в вышестоящих секциях "ВЫБРАТЬ". Что сложного в определении нужно ли нам то или иное поле? Самое смешное, что если мы дадим подсказку: дескать это поле может быть не нужным, то программа вдруг поумнеет и все сделает. Тоже самое касается таблиц: еще можно было представить, что данное объединение используется не для получения полей, а для фильтрации исходной таблицы. Но ведь все объединения ЛЕВЫЕ! Что трудного в самостоятельном определении выборки полей из таблицы? Вот так и не понял этого функционала прикрученного сбоку.

Понимание придет с первым отчетом на запросе "повышенной сложности" :)

Причем тут понимание? Когда реально платформа сама может все сделать без дополнительных глупых настроек.

Платформа может сделать "сама" только в однозначных ситуациях.

Может кто-нибудь привести пример простейшего запроса, в котором не обойтись без описанного выше?

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

Скобочки {} - это возможность задать список доступных полей (отборов) для пользователя. Остальное все - побочные эффекты

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