Работа с GUID ссылок в запросах 1С Предприятие

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

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

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

Природа уникального идентификатора в 1С

Каждый объект метаданных в базе данных 1С хранится с привязкой к уникальному ключу. Этот ключ имеет тип УникальныйИдентификатор и занимает 16 байт. В отличие от числовых идентификаторов (ссылки), которые могут меняться при перезагрузке конфигурации или в некоторых сценариях обмена, GUID остается неизменным в течение всего жизненного цикла объекта.

Важно понимать, что ссылка на объект в 1С — это составной тип данных. Она содержит информацию о виде ссылки (таблице) и уникальный номер записи. Однако в контексте запросов нас часто интересует именно внутреннее представление этого номера. Для работы с ним используется специальный тип данных УникальныйИдентификаторСтроки, который позволяет хранить GUID в текстовом формате.

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

⚠️ Внимание: Не пытайтесь хранить GUID в обычном текстовом поле без соблюдения формата. Стандартный формат включает дефисы и имеет строгую структуру 8-4-4-4-12 символов.

Функция УникальныйИдентификатор в языке запросов

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

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

ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка,
УникальныйИдентификатор(Номенклатура.Ссылка) КАК ГУИД
ИЗ
Справочник.Номенклатура КАК Номенклатура

Результатом выполнения такого запроса будет таблица, где в поле ГУИД будет содержаться строковое представление идентификатора. Это значение можно сразу использовать для JOIN с внешними таблицами или выгрузки в XML/JSON формат без дополнительного программирования на языке 1С.

Стоит отметить, что функция работает только с полями типа Ссылка. Попытка применить её к числовому полю или строке приведет к ошибке синтаксиса при компиляции запроса. Также функция корректно обрабатывает пустые значения, возвращая NULL, если ссылка не заполнена.

Преобразование строки в УникальныйИдентификатор

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

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

ВЫБРАТЬ
Номенклатура.Ссылка,
Номенклатура.Наименование
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
УникальныйИдентификатор(Номенклатура.Ссылка) В
(ВЫБРАТЬ
ВременнаяТаблица.ГУИД
ИЗ
ВременнаяТаблица)

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

• 🔹 Функция УникальныйИдентификаторСтроки чувствительна к формату входной строки.
• 🔹 Допустимы форматы как с фигурными скобками {...}, так и без них.
• 🔹 Регистр букв в шестнадцатеричном представлении не имеет значения (A равно a).

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

Сравнение ссылок и GUID в условиях запроса

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

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

При написании сложных запросов с объединениями (ОБЪЕДИНИТЬ) убедитесь, что типы полей в выбираемых списках совпадают. Если в первом запросе вы выбираете ссылку, а во втором — GUID, структура результирующей таблицы будет нарушена.

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

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

Использование функций преобразования типов в условиях отбора (ГДЕ) может негативно сказаться на производительности запроса. Когда вы пишете условие вида ГДЕ УникальныйИдентификатор(Ссылка) = Значение, серверу 1С может потребоваться вычислить функцию для каждой строки таблицы, что препятствует использованию индекса по полю Ссылка.

// Пример получения GUID конкретного элемента
ЗначениеСсылки = Справочники.Номенклатура.НайтиПоНаименованию("Товар А");
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|   УникальныйИдентификатор(&Ссылка) КАК GUID
|ИЗ
|   Справочник.Номенклатура КАК Номенклатура";
Запрос.УстановитьПараметр("Ссылка", ЗначениеСсылки);
Результат = Запрос.Выполнить();
// В результате получим строку вида: 550e8400-e29b-41d4-a716-446655440000