При проектировании систем интеграции и обмена данными часто возникает соблазн использовать один и тот же Уникальный Идентификатор (GUID/UUID) для логически связанных объектов, которые физически хранятся в разных справочниках или документах. Типичный пример: один справочник из «Базы-источника» при миграции разделяется на два разных справочника в «Базе-приемнике», или когда документ «Продажа» зеркалируется в документ «Покупка» с сохранением того же идентификатора для обеспечения неразрывной связи.
В этой статье мы подробно проанализируем, насколько корректен такой подход с точки зрения платформы «1С:Предприятие», разберем внутренние механизмы хранения данных и выясним, какие риски могут возникнуть при написании запросов и работе с интерфейсами.
Для начала проанализируем, как платформа 1С взаимодействует с базой данных (SQL Server, PostgreSQL и др.). Рассмотрим внутреннюю структуру таблиц. Каждый объект метаданных (справочник, документ) в 1С соответствует отдельной таблице в СУБД. Например, Справочник.Номенклатура может храниться в таблице _Reference15, а Справочник.Контрагенты — в _Reference20.
Поле _IDRRef, в котором хранится 16-байтное двоичное представление GUID, является первичным ключом (Primary Key) именно для конкретной таблицы. Поскольку таблицы разные, СУБД не видит конфликта, если в них появятся строки с одинаковыми значениями в поле _IDRRef. Платформа 1С гарантирует уникальность GUID только в рамках одного типа метаданных (одной таблицы). Таким образом, технически создание элементов с одинаковыми GUID в разных справочниках полностью допустимо и не вызывает ошибок на уровне базы данных.
Рассмотрим ситуацию, когда в системе используются реквизиты составного типа (например, поле «Владелец» или «ДокументОснование»). Выясним, как система понимает, на какой именно объект ссылается идентификатор, если он дублируется в разных таблицах.
В базе данных для хранения составного типа 1С выделяет несколько колонок:
Благодаря наличию идентификатора типа (TRef), система всегда точно знает, к какой таблице нужно обратиться. Даже если GUID совпадает у элемента Справочник1 и Справочник2, связка «Тип + GUID» всегда будет уникальной в масштабах всей базы данных. Это фундаментальный принцип работы ссылочной целостности 1С.
Несмотря на техническую поддержку, существуют нюансы при работе с языком запросов 1С. Проанализируем ситуацию, когда мы обращаемся к реквизитам через точку от поля составного типа. Если в поле хранится ссылка, и мы пытаемся получить ее реквизит, платформа выполняет неявное соединение (LEFT JOIN) со всеми возможными таблицами, входящими в составной тип.
Если в разных справочниках есть объекты с одинаковыми GUID, и вы программно или через запрос пытаетесь «достучаться» до данных, не указывая тип явно, могут возникнуть сложности с производительностью или логикой. Рассмотрим пример правильного обращения в запросе:
ВЫБРАТЬ
ВЫРАЗИТЬ(ИсходныеДанные.ДокументОснование КАК Документ.ПоступлениеТоваровУслуг).Номер КАК НомерПоступления,
ВЫРАЗИТЬ(ИсходныеДанные.ДокументОснование КАК Документ.РеализацияТоваровУслуг).Номер КАК НомерРеализации
ИЗ
РегистрСведений.СвязиДокументов КАК ИсходныеДанные
Использование оператора ВЫРАЗИТЬ крайне рекомендуется. Это не только оптимизирует запрос, исключая лишние соединения таблиц, но и явно указывает платформе, из какой таблицы брать данные, полностью нивелируя проблему одинаковых GUID.
Посмотрим на реальный опыт разработки. Часто такой метод применяется для жесткой связки объектов. Например, при создании обработки «Зеркальное отражение документов»:
УникальныйИдентификатор, как у «Продажи».Пример кода для программного создания объекта с заданным GUID:
НовыйGUID = СсылкаИсточник.УникальныйИдентификатор();
НоваяСсылка = Документы.ПокупкаТоваровУслуг.ПолучитьСсылку(НовыйGUID);
НовыйОбъект = Документы.ПокупкаТоваровУслуг.СоздатьДокумент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
// Заполнение реквизитов...
НовыйОбъект.Записать();
Этот метод «приколачивает намертво» связь между объектами, которую сложно разорвать обычными махинациями в интерфейсе.
Проанализируем ситуации, в которых одинаковые GUID могут стать проблемой:
Тип + GUID.Подведем итог нашему анализу. Использование одинаковых GUID в разных справочниках — это рабочий и допустимый инструмент, если вы четко понимаете механику его работы.
Основные правила:
ВЫРАЗИТЬ в запросах при работе с составными типами данных.Справочники.Номенклатура.ПолучитьСсылку(...)).Соблюдение этих простых правил позволит вам эффективно использовать возможности платформы по управлению уникальными идентификаторами без риска нарушения целостности данных.