Как получить доп реквизит 1С в запросе

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

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

Архитектура хранения дополнительных реквизитов

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

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

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

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

Использование виртуальной таблицы ДополнительныеРеквизиты

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

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

ВЫБРАТЬ
ДопРеквизиты.Ссылка КАК Ссылка,
ДопРеквизиты.Значение КАК ЗначениеДР
ИЗ
Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизиты
ГДЕ
ДопРеквизиты.ВидХарактеристики = &ВидХарактеристики

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

• 🔍 Используйте псевдонимы таблиц для улучшения читаемости кода запроса.
• 🚀 Фильтруйте данные по виду характеристики на уровне условия ГДЕ, а не в коде 1С после выборки.
• ⚙️ Проверяйте тип возвращаемого значения, так как поле Значение может быть составным.

Работа с составными типами и приведение данных

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

Для решения этой проблемы в языке запросов 1С предусмотрены функции приведения типов. Вы можете явно указать, к какому типу нужно привести поле, используя синтаксис КАК с указанием типа или специальные функции конвертации. Это особенно важно при формировании временных таблиц, куда вы планируете записывать результаты для дальнейшей обработки.

Рассмотрим ситуацию, когда в одном виде характеристик хранятся и строки, и числа. Прямое сравнение может не сработать корректно во всех СУБД. Рекомендуется использовать конструкцию ВЫРАЗИТЬ или явное приведение в списке полей. Это гарантирует, что СУБД поймет ваши намерения и построит оптимальный план выполнения.

⚠️ Внимание: При приведении типов убедитесь, что данные действительно соответствуют целевому типу. Попытка преобразовать текст "Абв" в число вызовет ошибку выполнения запроса, которая остановит всю обработку.

Оптимизация производительности при выборке больших объемов

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

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

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

Специфика работы в разных версиях платформы

Поведение механизма дополнительных реквизитов существенно менялось от версии к версии. В ранних релизах 8.2 и 8.3 доступ к данным был более ограниченным и требовал сложных обходных путей. В современных версиях (8.3.20+) механика стала более прозрачной, но появились новые ограничения на использование в распределенных информационных базах (РИБ).

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

Кроме того, в файловых вариантах баз данных производительность выборок из таблиц расширений может быть ниже, чем в клиент-серверном варианте с PostgreSQL или MS SQL. Это связано с особенностями реализации движка хранения данных. Тестирование запросов на реальных объемах данных обязательно перед выкаткой в продуктивную среду.

Версия платформы	Особенность хранения	Рекомендуемый метод	Производительность
8.2 - 8.3.5	Отдельные регистры сведений	Прямые соединения	Низкая при больших объемах
8.3.6 - 8.3.15	Унифицированные таблицы	Виртуальные таблицы	Средняя
8.3.20+	Оптимизированные индексы	Виртуальные таблицы + Временные таблицы	Высокая
РИБ (Любая)	Фрагментарная синхронизация	Проверка наличия данных	Зависит от канала связи

Тонкости работы с РИБ

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

Отладка и анализ сформированных запросов

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

Обращайте внимание на наличие операций LEFT JOIN вместо INNER JOIN. Если вы уверены, что данные есть, использование внутреннего соединения может ускорить выполнение, так как оптимизатор СУБД сможет отбросить лишние строки на раннем этапе. Однако ошибка в логике здесь приведет к потере данных из основной выборки.

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

⚠️ Внимание: Интерфейс и возможности консоли запросов могут отличаться в разных версиях конфигуратора. Всегда сверяйтесь с документацией к конкретной версии платформы, если не можете найти нужную опцию отображения SQL-кода.

Часто задаваемые вопросы (FAQ)

Почему запрос к ДополнительнымРеквизитам возвращает пустые значения?

Скорее всего, вид характеристики указан неверно или не соответствует типу объекта. Также проверьте, заполнен ли реквизит в конкретных записях базы данных. В РИБ проблема может быть в отсутствии синхронизации данных.

Можно ли обновлять дополнительные реквизиты через запрос?

Нет, виртуальная таблица ДополнительныеРеквизиты доступна только для чтения. Для изменения данных необходимо использовать объект метода Записать() или специализированные обработки массового изменения.

Как получить доп. реквизит в СКД без написания кода?

В конструкторе запросов схемы компоновки данных выберите нужный объект, затем в списке доступных полей найдите папку «Дополнительные реквизиты». Перетащите нужную характеристику в набор данных.

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

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