Пролог
Для начала давайте вспомним, как работает динамический список. Обратим внимание именно на режим порционной выборки данных. В документации по платформе об этом очень ёмко сказано так: "Система автоматически выполняет считывание данных запроса порциями, по мере навигации пользователя по списку"
https://v8.1c.ru/platforma/dinamicheskiy-spisok/
Также на ИТС есть более подробное описание режимов порционной выборки:
Динамическое считывание данных включено (рекомендуется). Используются запросы, выбирающие записи в количестве, приблизительно соответствующем количеству видимых строк в таблице;
Динамическое считывание данных выключено, задана не виртуальная основная таблица или одна из следующих таблиц: СрезПервых, СрезПоследних, ЗадачиПоИсполнителю, КритерииОтбора, ДвижениеСубконто. Используются запросы, выбирающие по 1000 записей в буфер на сервере, по мере необходимости данные передаются на клиент. Менее эффективно, чем динамическое считывание;
https://its.1c.ru/db/v8std/content/732/hdoc
Суть, к чему я подвожу, - здесь одна:
Платформа автоматически накладывает на выборку данных в запросе динамического списка некоторые отборы, которые мы не видим, и управлять ими не можем!
Практика
В запросе динамического списка мы очень часто хотим обогатить выборку дополнительными данными.
Очень часто встречается соединение с выборкой текущих остатков, или среза последних цен.
Да, это не хорошо, не оптимально, и т.д. но именно такой пример приведен в документации по платформе, по первой ссылке. вот картинка оттуда :)
И это очень частая практика во многих кастомных разработках!
Да, при всём желании, на виртуальные таблицы в примере навряд ли наложатся ограничения по Товару, но на практике также бывает выборка полегче, например из табличных частей выводимых в списке документов, либо из других связанных с ними таблиц. И здесь уже можно подумать о наложении ограничений, чтобы не тянуть лишние данные.
Затруднения
Мы не всегда можем просто левым соединением добавить нужные поля из других таблиц.
для этого, мы сначала собираем нужные нам данные, обрабатываем, группируем и т.д.,
кладём их во временные таблицы запроса...
И, в итоговой выборке - к основной таблице динамического списка делаем левое соединение с временной таблицей, уже содержащей нужные нам данные в нужном виде.
Пример выборки таких данных
ВЫБРАТЬ
СправочникДоговорыКонтрагентов.Владелец КАК Владелец,
КОЛИЧЕСТВО(СправочникДоговорыКонтрагентов.Ссылка) КАК Количество
ПОМЕСТИТЬ ТаблицаКоличествоДоговоров
ИЗ
Справочник.ДоговорыКонтрагентов КАК СправочникДоговорыКонтрагентов
СГРУППИРОВАТЬ ПО
СправочникДоговорыКонтрагентов.Владелец
При подготовке дополнительных данных желательно разумно ограничить выборку. Понимаем, что в последней выборке будем присоединять левым соединением к основной таблице, но ограничить выборку хочется уже сейчас, когда мы помещаем её во временную таблицу.
Поэтому мы пишем примерно следующее:
...
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК ТаблицаОтбораКонтрагентов
ПО СправочникДоговорыКонтрагентов.Владелец = ТаблицаОтбораКонтрагентов.Ссылка
В надежде на то, что таблица "Справочник.Контрагенты" - это основная таблица динамического списка,
и мы предполагаем выборку данных порциями.
Но это не так!
Такая схема подхватывает все установленные на основную таблицу пользовательские отборы; размер нашей выборки во временной таблице действительно уменьшается, но ...
Есть проблема!
Когда мы пишем выборку из основной таблицы динамического списка, и помещаем её во временную таблицу, то порционная выборка тут не действует!
При отсутствии пользовательских отборов, во временную таблицу будут выбраны все данные. И даже с нашими или пользовательскими отборами, размер выборки может оказаться неприлично большим.
Это при том, что в финальной выборке, как заявлено, будет не более 1000 строк, или даже примерно 50 в случае, когда "Динамическое считывание данных включено".
Моё предложение
Я уже отправил предложение вендору на @platform_suggestions; мне даже через 5 дней ответили :)
Чего мне не хватает...
Иногда нам действительно нужно выбирать из основной таблицы все данные, либо накладывать иные отборы на неё, эта логика уже давно заложена в платформе 1С.
Но, вот если бы была возможность конкретно указать, что здесь и сейчас нам нужна порционная выборка данных... ?
Полностью аналогичная выборке основной таблицы динамического списка.
Например, применительно к выборке из основной таблицы, дописать в тексте запроса что-то вроде "Выбрать Динамически":
ВЫБРАТЬ // ДИНАМИЧЕСКИ
СправочникКонтрагенты.Ссылка КАК Ссылка
ПОМЕСТИТЬ ТаблицаОтбораКонтрагентов
ИЗ
Справочник.Контрагенты КАК СправочникКонтрагенты { ВЫБРАТЬ ДИНАМИЧЕСКИ }
Так, мы сможем ограничить любые наши дополнительные выборки данных только теми строками основной таблицы, которые будут фактически участвовать в запросе при формировании динамического списка.
При этом, существующая логика работы платформы никак не испортится.
Полный текст примера:
Есть и обратная сторона этой проблемы.
Однажды у меня никак не получалось выбрать из основной таблицы динамического списка все данные и поместить их во временную таблицу.
Всегда автоматически накладывались пользовательские отборы.
Пример такой надобности:
Когда данные справочника наполняются из разных мест, например, разных сервисов, классификаторов, и т.д. Они частично дублируются по некоторому критерию, например по ИНН, но получены из разных источников.
В этом случае хочется вывести в динамическом списке флаг наличия этого же элемента среди других источников, но сделать это не получится, если вдруг пользователь поставит отбор на текущий источник.
Вот если бы была возможность указать, что здесь нужна полная выборка...
ВЫБРАТЬ // ВСЕ
СправочникКонтрагенты.Ссылка КАК Ссылка
ПОМЕСТИТЬ ТаблицаОтбораКонтрагентов
ИЗ
Справочник.Контрагенты КАК СправочникКонтрагенты { ВЫБРАТЬ ВСЕ }
Эпилог
Думаю, что это не только моя боль...
Считаю, что технически организовать этот функционал в платформе - задача относительно не сложная, но при этом очень полезная.
Надеюсь, что разработчики платформы меня услышат, и однажды мы сможем писать запросы в динамическом списке более оптимально
Прошу считать эту статью моим "открытым письмом" к Вендору 1С :)
Вступайте в нашу телеграмм-группу Инфостарт
