В процессе разработки и интеграции систем на платформе 1С:Предприятие часто возникает вопрос: можно ли полагаться на абсолютную уникальность Уникального Идентификатора (UUID) во всей информационной базе? Этот вопрос становится критическим при проектировании внешних систем хранения данных, веб-сервисов или сложных механизмов обмена. Давайте подробно разберем, как устроена ссылочная идентификация в 1С, что именно гарантирует платформа и как это выглядит на уровне систем управления базами данных (СУБД).
Для начала проанализируем, что представляет собой «ссылка» на объект (справочник, документ, бизнес-процесс). Вопреки распространенному мнению, в 1С ссылка — это не просто набор из 36 символов (строковое представление UUID). На уровне архитектуры платформы ссылка является составной сущностью. Рассмотрим ее структуру:
550e8400-e29b-41d4-a716-446655440000.Рассмотрим ситуацию: если мы возьмем один и тот же UUID и программно присвоим его элементам разных справочников, платформа это позволит. С точки зрения 1С это будут абсолютно разные ссылки, потому что их «типовая» часть различается. Таким образом, мы приходим к важному выводу: уникальность идентификатора гарантируется платформой только в пределах объектов одного типа (одной таблицы СУБД).
Давайте обратимся к синтакс-помощнику и проанализируем работу метода УстановитьСсылкуНового(). Разберем по шагам, что происходит при его вызове:
Метод позволяет программисту заранее определить, какой UUID будет у объекта после записи. В документации прямо указано: «Значение не может равняться ссылке какого-либо из имеющихся в базе данных объекта данного типа. Уникальность ссылки проверяется при записи объекта».
Это означает, что при выполнении метода Объект.Записать() платформа выполняет запрос к конкретной таблице в СУБД, проверяя наличие дубля только в ней. Если вы попытаетесь записать СправочникОбъект.Номенклатура с идентификатором, который уже есть в Справочник.Контрагенты, система не выдаст ошибки и успешно создаст запись.
Посмотрим на пример кода, который демонстрирует возможность существования одинаковых UUID в разных таблицах:
// Создадим новый идентификатор
НовыйУИД = Новый УникальныйИдентификатор();
// Попробуем назначить его справочнику Контрагенты
НовыйКонтрагент = Справочники.Контрагенты.СоздатьЭлемент();
НовыйКонтрагент.УстановитьСсылкуНового(Справочники.Контрагенты.ПолучитьСсылку(НовыйУИД));
НовыйКонтрагент.Наименование = "Тестовый контрагент";
НовыйКонтрагент.Записать();
// Попробуем назначить ЭТОТ ЖЕ идентификатор справочнику Номенклатура
НоваяНоменклатура = Справочники.Номенклатура.СоздатьЭлемент();
НоваяНоменклатура.УстановитьСсылкуНового(Справочники.Номенклатура.ПолучитьСсылку(НовыйУИД));
НоваяНоменклатура.Наименование = "Тестовая номенклатура";
НоваяНоменклатура.Записать();
В результате выполнения этого кода в базе появятся два разных объекта с идентичными UUID. Это доказывает, что в масштабе всей базы данных один лишь UUID не является уникальным ключом.
Проанализируем структуру таблиц на уровне Microsoft SQL Server или PostgreSQL. Для каждого ссылочного типа создается отдельная физическая таблица (например, _Reference10). Поле, хранящее идентификатор, обычно называется _IDRRef и имеет тип binary(16).
Индекс первичного ключа (Primary Key) строится именно по полю _IDRRef внутри каждой конкретной таблицы. Общего индекса, объединяющего все таблицы базы данных по полю идентификатора, не существует. Именно поэтому проверка уникальности на уровне базы данных ограничена рамками одной таблицы.
Также стоит обратить внимание на составные типы данных. Если у вас есть реквизит с типом «Любая ссылка», в таблице СУБД для него выделяется несколько колонок:
_Fld123_TYPE — двоичные данные, определяющие тип таблицы._Fld123_RRef — сам 128-битный идентификатор.Это еще раз подтверждает, что для однозначного поиска объекта в базе данных платформе 1С жизненно необходимо знать оба компонента: тип и идентификатор.
Выясним, насколько вероятно случайное совпадение идентификаторов, если не назначать их вручную. Платформа 1С использует стандарт UUID (Universally Unique Identifier), вероятность коллизии в котором ничтожно мала. Даже если генерировать миллиарды объектов в секунду, шанс случайного совпадения математически стремится к нулю.
Однако в 1С есть особенность: последовательные GUID. Для оптимизации работы индексов (чтобы новые записи добавлялись в конец B-дерева и не вызывали фрагментацию), 1С генерирует идентификаторы, которые частично зависят от времени и сеанса. Это делает их «упорядоченными». Несмотря на этот алгоритм, глобальная уникальность при автоматической генерации сохраняется очень высокой, и встретить два одинаковых UUID, созданных платформой автоматически в разных таблицах, практически невозможно.
Если перед нами стоит задача «сливать» данные из разных таблиц 1С в одну плоскую таблицу во внешней системе (например, в BI-систему или внешнюю SQL-базу), использование только UUID в качестве первичного ключа является архитектурной ошибкой. Проанализируем правильные подходы:
"Ref_Contr_" + Строка(УИД).ПубличныеИдентификаторыОбъектов, которые помогают сопоставлять объекты при обменах, но даже там логика опирается на уникальность внутри типа.Подведем итог: хотя 1С и называет идентификатор «уникальным», его уникальность — это свойство, гарантированное платформой только в контексте конкретного типа данных. При разработке сложных систем всегда учитывайте типовую принадлежность ссылки, чтобы избежать коллизий и логических ошибок.