Работа с условием в запросе 1С для дополнительных реквизитов

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

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

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

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

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

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

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

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

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

Базовый синтаксис условия в запросе

Самый распространенный способ фильтрации по дополнительному реквизиту — это использование конструкции ЕСТЬ внутри раздела ГДЕ запроса. Этот оператор позволяет проверить наличие записи в таблице значений свойств для конкретного объекта и конкретного свойства. Синтаксически это выглядит как подзапрос или специальное условие существования связи.

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

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

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

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

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

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

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

Ключевым фактором оптимизации является наличие и правильное использование индексов. Платформа 1С автоматически создает индексы для основных полей, но для дополнительных реквизитов ситуация сложнее. Индексация может быть настроена только для тех свойств, которые помечены как «Индексировать» в конфигураторе. Без этой галочки любой запрос будет приводить к полному сканированию таблицы (Table Scan).

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

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

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

// Шаг 1: Отбор ссылок во временную таблицу
ВЫБРАТЬ
Номенклатура.Ссылка
ПОМЕСТИТЬ ВТ_Отбор
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
Номенклатура.ДополнительныеРеквизиты.СерийныйНомер = &ПараметрСерии

// Шаг 2: Основная выборка по временной таблице
ВЫБРАТЬ
ВТ_Отбор.Ссылка,
Номенклатура.Наименование
ИЗ
ВТ_Отбор КАК ВТ_Отбор
INNER JOIN Справочник.Номенклатура КАК Номенклатура
ПО ВТ_Отбор.Ссылка = Номенклатура.Ссылка

Работа с таблицами значений и сложными типами

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

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

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

Тип данных	Особенность хранения	Рекомендация по сравнению
Строка	Хранится как есть, чувствительно к регистру в некоторых СУБД	Использовать ПОДОБНО для нечеткого поиска
Число	Может храниться с разной точностью	Приводить к целому или фиксированной точности
Булево	Хранится как 0 или 1	Сравнивать с ИСТИНА/ЛОЖЬ явно
Ссылка	Хранится как UID объекта	Сравнивать только с ссылками того же типа

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

Как передать таблицу значений в запрос?

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

Использование регулярных выражений и функций

В некоторых сценариях простого сравнения на равенство недостаточно. Например, нужно найти все товары, у которых артикул начинается на «А-10» или содержит определенную маску. Для таких задач в запросах 1С используется оператор ПОДОБНО, который поддерживает синтаксис регулярных выражений, схожий с SQL.

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

Если вы используете ПОДОБНО с ведущим символом процента (например, ПОДОБНО "%123"), база данных практически всегда будет выполнять полное сканирование, так как она не может использовать индекс для поиска подстроки в конце значения. Старайтесь формировать условия так, чтобы переменная часть была в конце строки.

• 🔍 Оператор ПОДОБНО регистрозависим в зависимости от настроек collation базы данных.
• 🔍 Избегайте использования функций вроде ЛЕВЫЙ или ПОДСТРОКА в левой части условия.
• 🔍 Для поиска по маске лучше использовать полнотекстовый поиск, если он настроен в конфигурации.

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

⚠️ Внимание: Интерфейс и возможности полнотекстового поиска зависят от версии платформы и типа используемой СУБД (MSSQL, PostgreSQL, Oracle). Проверяйте документацию для вашей конкретной конфигурации перед внедрением сложных поисковых масок.

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

Когда стандартные механизмы дополнительных реквизитов не обеспечивают требуемой производительности или гибкости, архитекторы 1С прибегают к альтернативным решениям. Одним из таких решений является вынос часто используемых для отборов свойств в отдельные регистры сведений.

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

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

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

Можно ли использовать дополнительные реквизиты в СКД (Система Компоновки Данных)?

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

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

Физические имена таблиц начинаются с _AddRc и содержат хэш от имени объекта метаданных. Узнать точное имя можно через консоль запросов или администрирование сервера 1С, но использовать эти имена в коде не рекомендуется.

Влияет ли удаление дополнительного реквизита на размер базы данных?

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

Почему запрос с условием по ДР работает медленно только у некоторых пользователей?

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

Можно ли сделать дополнительный реквизит уникальным?

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