1с запрос динамического списка не должен содержать объединения

Обновлено: 07.07.2024

Запросы в динамических списках

Область применения: управляемое приложение, мобильное приложение.

Методическая рекомендация (полезный совет)

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

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

Пример

В динамическом списке документов-распоряжений на отгрузку нужно вывести состояние отгрузки. Состояние зависит от остатков регистра накопления, и статусов двух документов другого типа.

НЕПРАВИЛЬНО

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

ПРАВИЛЬНО

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

2. Необходимо выбрать один из трех режимов работы динамического списка:

Динамическое считывание данных включено (рекомендуется). Используются запросы, выбирающие записи в количестве приблизительно соответствующем количеству видимых строк в таблице;
Динамическое считывание данных выключено, задана не виртуальная основная таблица или одна из следующих таблиц: СрезПервых, СрезПоследних, ЗадачиПоИсполнителю, КритерииОтбора, ДвижениеСубконто. Используются запросы, выбирающие по 1000 записей в буфер на сервере, по мере необходимости данные передаются на клиент. Менее эффективно, чем динамическое считывание;
Динамическое считывание данных выключено, основная таблица не задана. Запрос выполняется «как есть». В буфере накапливаются данные, начиная с 1000 записей. Чем ближе к концу списка, тем больше записей. Можно использовать только для заведомо маленьких выборок.

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

По которым выполняется соединение в запросе;
На которые наложены условия в запросе;
Выведенных в качестве быстрых отборов;
По которым выполняется упорядочивание или предусмотрена группировка;
По которым ожидается, что пользователь будет часто упорядочивать (группировать).

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

4. Настоятельно не рекомендуется использовать конструкции, «утяжеляющие» запрос:

конструкции РАЗЛИЧНЫЕ и СГРУППИРОВАТЬ ПО;
конструкции ВЫБОР в предложении ГДЕ или в условиях соединения;
упорядочивание по полю, полученному при помощи конструкции ВЫБОР, в том числе и пользовательское.

5.1 Соединяться в запросе следует только с небольшим количеством реальных таблиц (в оптимальном варианте в динамическом списке – только одна таблица, и она назначена основной).

Не рекомендуется выполнять соединения:

с большим количеством реальных таблиц. Ориентироваться стоит на количество не более 4 таблиц;
с вложенными запросами;
с виртуальными таблицами.

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

допустимо соединение с виртуальными таблицами СрезПоследних (СрезПервых), если регистр сведений содержит
заведомо небольшое количество записей. Например, получение текущего курса валют по данным регистра сведений КурсыВалют;
при обращении к виртуальной таблице будут использованы хранимые итоги регистра сведений (см. Разрешение итогов для периодических регистров сведений);
запрос к виртуальной таблице Остатки будет преобразован платформой в простое чтение хранимой таблицы итогов без группировок (см. Эффективное обращение к виртуальной таблице «Остатки»).

5.3. Временные таблицы в динамических списках следует использовать с учетом требований описанных ниже и в стандарте про использование временных таблиц.

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

5.3.2. В частности, если не удается переделать запрос динамического списка, используя виртуальные таблицы с ограничениями (см. п. 5.2), или вообще отказавшись от их использования, то вместо соединения с ними следует использовать соединения с временными таблицами.

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

5.4. При учете количества таблиц, участвующих в запросе, необходимо помнить, что обращение к полям «через точку» приводит к неявному соединению с дополнительными таблицами. Подробнее см.: Разыменование ссылочных полей составного типа в языке запросов

5.5. При работе со списком под неполными правами, в которых настроены ограничения доступа к данным (RLS) к таблицам, участвующим в запросе*, также автоматически присоединяются условия ограничения доступа к данным, которые замедляют работу списка. Именно в этом режиме работы следует проверять скорость работы динамических списков.

* примечание: к тем таблицам, к которым предусмотрен RLS в конфигурации.

6. Предусмотреть оптимизацию при работе с полями составного типа

При использовании в соединениях, отборах, упорядочивании и других конструкциях составного поля, необходимо чтобы состав типов данного поля определялся только ссылочными типами. Подробнее см.: Ограничения на использование реквизитов составного типа;
Если известно заранее, какого типа должно быть получено поле составного типа, то его необходимо выражать.

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

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

8. Если применение вышеизложенных рекомендаций не возможно, либо оно не дает должного эффекта, то можно рассмотреть следующие пути оптимизации:

8.1. Отказаться от части возможностей динамического списка.

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

8.2. Осуществлять вывод данных не в динамический список, а в таблицу или дерево значений.

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

Данный способ применим, если выполняется одно из условий:

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

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

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

Кроме того, для корректной работы динамического списка требуется явно ограничить выполнение отбора, сортировки и группировки по вспомогательным колонкам с помощью методов динамического списка УстановитьОграниченияИспользованияВГруппировке , УстановитьОграниченияИспользованияВПорядке и УстановитьОграниченияИспользованияВОтборе .

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

СВЯЗИ ПАРАМЕТРОВ ВЫБОРА

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

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

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

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

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

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

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

ПАРАМЕТРЫ ВЫБОРА

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

Платформа накладывает следующие ограничения на создание выражений условий связей параметров. Имя параметра должно удовлетворять условиям написания имен (не содержать пробелов, начинаться может с буквы или символа подчеркивание); в имени можно использовать только одну точку или не использовать точку вообще. Значение параметра должно быть значением реквизита формы без использования подчиненных реквизитов, однако можно указать реквизит табличной части в специальном формате через элементы формы: Элементы.Список.ТекущиеДанные.ИмяРеквизита.

ОБХОД ОГРАНИЧЕНИЙ ПАРАМЕТРОВ ВЫБОРА

Практика

На практике мне попадались следующие решения:

Передача в параметры формы выбора подготовленного списка ссылок для выбираемого типа данных
Использование специализированной формы выбора с предопределенным запросом динамического списка
Выбор из подготовленного списка значений

Недостатками этих решений являются:

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

Решение

В рамках наложенных ограничений платформы, недостающие параметры можно передать косвенно через указание реквизита формы. Так, если по приведенному примеру выше, нам нужно указать связь по родителю реквизита Контрагент, то условие связи параметров может быть таким: Отбор.КонтрагентРодителя = Контрагент. Тогда в форму выбора или же в предопределенную процедуру обработки выбора будет передан параметр с именем КонтрагентРодителя и значением реквизита формы Контрагент. Далее нам достаточно отработать условие по этому параметру, а именно использовать этот параметр для получения значения через точку Контрагент.Родитель и уже это, полученное косвенно, значение параметра использовать для установки необходимого отбора по родителю.

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

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

ПОДСИСТЕМА РАБОТА С ДАННЫМИ ВЫБОРА

Рисунок 1. Диаграмма последовательности

Предлагаемая подсистема реализует интерфейс для работы следующих сценариев:

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

Подключение к подсистеме производится через вставку вызова в форме выбора и добавление предопределенной процедуры менеджера объекта ОбработкаПолученияДанныхВыбора.

Обработка параметров, функция ПолучитьТекстЗапроса

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

Основное назначение функции - в получении текста запроса по переданным параметрам. В отличии от стандартного поведения платформы, когда в форму выбора передаются параметры, эта функция не имеет ограничений: в ней можно реализовать любые условия выбора. Однако и здесь есть ограничение платформы: результирующий запрос не должен содержать объединений ни в одном из пакетов запроса. Это ограничение накладывается реализацией динамического списка, в котором на текущий момент объединения не поддерживаются (однако объединение можно использовать во вложенном запросе!).

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

Листинг 1. Общая структура функции ПолучитьТекстЗапроса на примере справочника _ДемоНоменклатура

Динамический список формы выбора

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

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

Для работа подсистемы необходимо настроить динамический список формы выбора: установить произвольный запрос и изменить псевдоним основной таблицы на имя "Источник".

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

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

Листинг 2. Демонстрация разделения параметров в функции ПолучитьТекстЗапроса

Листинг 3. Подключение формы выбора к подсистеме

Примечание: подключаемая форма выбора должна содержать произвольный текст запроса основной таблицы, при этом псевдоним основной таблицы должен быть предопределенным «Источник». Этот же псевдоним используется в подсистеме для построения текста запроса путем добавления условия и соединений.

Список данных выбора

Рисунок 2. Список выбора

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

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

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

Листинг 4. Подключение процедуры к подсистеме

Проверка на соответствие условиям параметров выбора. Заполнение по-умолчанию.

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

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

Листинг 5. Проверка соответствия переменной СсылкаНаЗначение переданным параметрам выбора из структуры Параметры

СТЕНД "РАБОТА С ДАННЫМИ ВЫБОРА"

Рисунок 3. Форма обработки стенда

Для демонстрации работы подсистемы выбран справочник _ДемоНоменклатура из демо-конфигурации БСП. С помощью расширения конфигурации в справочнике доработан менеджер объекта и форма выбора. В модуль менеджера добавлена функция ПолучитьТекстЗапроса и предопределенная процедура ОбработкаДанныхВыбора. В форме выбора добавлен вызов процедуры ЗаполнитьТекстЗапросаДинамическогоСписка.

В функции ПолучитьТекстЗапроса реализована обработка дополнительных параметров:

Организация и Контрагент - формируется список номенклатуры, которая использовалась в документах реализации
Договор контрагента - формируется список номенклатуры, определенный в регистре сведений НоменклатураДоговора
Дополнительные реквизиты - отбор по реквизитам из табличной части номенклатуры
Дополнительные свойства - отбор по свойствам, определенным в регистре сведений СвойстваОбъектов

В процедуре используются приемы по формированию текста запроса в объектной модели с использованием подсистемы РаботаСоСхемойЗапроса. Более подробно читайте здесь.

В процессе изучения 8.2 набросал консоль запросов и столкнулся с кучей различных проблем - от не правильного поведения элементов формы, до падения платформы с ошибкой. Стало интересно и немного повозившись сделал "стабильную" консоль запросов, которая не обрушивает платформу, покрайней мере предыдущие случаи падения платформы не воспроизводятся :).

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

Что интересного в этой консоли:

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

Общие ограничения:
· динамический список не поддерживает работу с пакетными запросами;
· в случае если динамический список отображается в виде иерархического списка или дерева, запрос не должен содержать условий
отбора по родителю;
· При программном изменении свойств динамического списка не происходит автоматического перезаполнения
командных панелей, связанных с этим динамическим списком;

Если задана основная таблица:
· динамический список не поддерживает в запросе объединения, если задана основная таблица;
· динамический список не должен содержать секции УПОРЯДОЧИТЬ ПО, если задана основная таблица.
· в числе полей запроса нельзя использовать поля подзапросов, возвращающих множественное количество значений. Необходимо
использовать запрос без основной таблицы;
· запрос не может содержать группировок и агрегатных функций, если задана основная таблица.
· в случае указания основной таблицы динамического списка запрос не должен содержать инструкций ПЕРВЫЕ и РАЗЛИЧНЫЕ.

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

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

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