Как выбрать GUID в запросе 1С: работа с уникальными идентификаторами

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

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

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

Синтаксис выборки поля УникальныйИдентификатор

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

Однако стоит помнить, что при получении данных в объект Запрос или ВыборкаИзРезультатаЗапроса, значение будет представлено именно как объект типа УникальныйИдентификатор, а не как строка. Это означает, что прямой вывод такого значения в макет или табличный документ без предварительного преобразования может привести к отображению служебного строкового представления, отличного от канонического формата UUID, ожидаемого внешними системами.

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

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

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

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

Преобразование GUID в строку внутри запроса

Наиболее частая задача при работе с идентификаторами — это необходимость получить их строковое представление непосредственно на уровне СУБД или движка запросов 1С. Это требуется для выгрузки данных в XML, JSON или для сопоставления с записями в внешних базах данных, где ключом служит строка формата UUID. В языке запросов 1С для этой цели используется встроенная функция ЕСТЬNULL в связке с приведением типов, однако более надежным способом является использование функции СТРОКА или явное приведение.

Начиная с определенных версий платформы, стало возможным использовать функцию ПРЕДСТАВЛЕНИЕ или специализированные методы конвертации, но самым универсальным и переносимым способом остается приведение типа к строке через конструкцию КАК СТРОКА или использование функции ФОРМАТ в коде обработки результата. Тем не менее, если вам критично выполнить преобразование именно в тексте запроса (например, для объединения в ОБЪЕДИНИТЬ со строковой таблицей значений), следует использовать функцию СТРОКА.

Рассмотрим пример запроса, где мы сразу получаем строковое представление GUID в стандартном формате:

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

Такой подход позволяет избежать лишних циклов обработки в коде 1С и перекладывает задачу форматирования на оптимизированный механизм выполнения запросов. Стоит учитывать, что строковое представление занимает больше места в оперативной памяти по сравнению с бинарным форматом (36 символов против 16 байт), поэтому не стоит злоупотреблять этим преобразованием при выборке миллионов строк, если строка не используется для фильтрации.

Технические детали формата

Внутренне 1С хранит GUID как 16-байтовый массив. При конвертации в строку добавляются дефисы и происходит перевод байтов в шестнадцатеричное представление. Порядок байт (Big Endian или Little Endian) может отличаться в зависимости от версии платформы и настроек СУБД, поэтому для критичных обменов лучше использовать стандартные функции платформы, а не ручную сборку строки.

Фильтрация и сравнение уникальных идентификаторов

Использование поля УникальныйИдентификатор в условиях отбора ГДЕ требует особого внимания к типам данных передаваемых параметров. Если вы сравниваете поле типа УникальныйИдентификатор со строковой константой, запрос может не сработать корректно или выдать ошибку типов, в зависимости от контекста и версии платформы. Правильным подходом является использование параметров запроса с явно указанным типом.

При формировании условия сравнения убедитесь, что значение, передаваемое в запрос, является именно объектом УникальныйИдентификатор. Если у вас есть строковое значение, полученное из внешнего источника, его необходимо предварительно преобразовать с помощью функции УникальныйИдентификатор() в коде перед установкой параметра. Прямое сравнение в тексте запроса вида ГДЕ УникальныйИдентификатор = "значение-строки" является ошибочным.

Пример корректной установки параметра и использования его в запросе:

• 🔹 Создайте объект запроса и получите текст запроса с параметром &ПараметрGUID.
• 🔹 В коде 1С создайте значение: Новый УникальныйИдентификатор("72300000-0000-0000-0000-000000000000").
• 🔹 Установите параметр: Запрос.УстановитьПараметр("ПараметрGUID", ЗначениеGUID).
• 🔹 Выполните запрос, где условие выглядит как ГДЕ УникальныйИдентификатор = &ПараметрGUID.

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

Сравнение производительности: GUID vs Ссылка

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

В таблице ниже приведено сравнение основных характеристик использования этих полей в запросах:

Характеристика	Ссылка (Ref)	УникальныйИдентификатор (GUID)
Размер в БД	8-16 байт (зависит от СУБД)	16 байт (фиксировано)
Индексация	Автоматическая (кластерный индекс)	Требует создания отдельного индекса
Уникальность	Уникальна в пределах вида объекта	Глобально уникальна (теоретически)
Скорость JOIN	Максимальная (оптимизировано ядром)	Высокая (при наличии индекса)

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

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

Работа с NULL значениями и пустыми GUID

Важным аспектом, который часто упускают из виду, является возможность наличия пустых значений. Поле УникальныйИдентификатор может принимать значение NULL (Неопределено), если объект еще не записан в базу данных или если поле не заполнено. В запросах это необходимо обрабатывать явно, используя функцию ЕСТЬNULL, чтобы избежать потери строк в выборке или ошибок при преобразовании типов.

Ситуация усугубляется тем, что "пустой" GUID (состоящий из одних нулей: 00000000-0000-0000-0000-000000000000) и значение NULL — это разные сущности. Пустой GUID является валидным значением типа, тогда как NULL означает отсутствие значения. При интеграции с внешними системами часто требуется подменять NULL на пустой GUID или наоборот, в зависимости от требований принимающей стороны.

Для корректной обработки используйте конструкцию:

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

Здесь параметр &ПустойGUID должен быть предварительно установлен в значение Новый УникальныйИдентификатор(). Это гарантирует, что в результирующем наборе данных не будет неопределенных значений, что упрощает дальнейшую сериализацию в JSON или XML.

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

Генерация новых GUID в запросах и коде

Хотя язык запросов 1С ориентирован на чтение данных, в некоторых сценариях (например, при использовании временных таблиц или запросов к регистрам сведений в режиме записи через встроенные механизмы) может потребоваться генерация новых идентификаторов. Стоит отметить, что стандартный SQL-синтаксис функции NEWID() или аналогов не поддерживается напрямую в тексте запроса 1С как выражение в списке полей ВЫБРАТЬ.

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

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

• 🔸 Сформируйте таблицу значений с необходимыми данными.
• 🔸 Добавьте колонку типа УникальныйИдентификатор.
• 🔸 Пройдитесь циклом по строкам и присвойте Новый УникальныйИдентификатор().
• 🔸 Запишите таблицу во временное хранилище для использования в запросе.

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

Частые ошибки и способы их устранения

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

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

Другая частая проблема связана с производительностью при соединении (JOIN) таблиц по полю GUID, если на одной из таблиц отсутствует индекс. В отличие от соединений по ссылкам, которые оптимизируются автоматически, соединения по произвольным полям требуют ручного контроля индексов. Если вы заметили, что запрос "висит" при соединении по GUID, проверьте свойства поля в конфигураторе.

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

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

Можно ли использовать GUID в качестве основного ключа в регистре сведений?

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

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

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

В чем разница между УникальныйИдентификатор и Ref в SQL?

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

Почему запрос не находит запись по GUID, хотя она есть?

Наиболее вероятная причина — несоответствие типов. Вы сравниваете поле типа УникальныйИдентификатор со строкой. Убедитесь, что параметр запроса имеет тип УникальныйИдентификатор, а не Строка, даже если содержимое визуально совпадает.

Можно ли изменить GUID у существующего объекта?

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