← На главную

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

Природа GUID и его уникальность

GUID представляет собой 128-битное число, которое должно обеспечивать уникальность объекта в глобальном масштабе. В платформе 1С алгоритм генерации GUID учитывает отметку времени и параметры оборудования (например, MAC-адрес сетевой карты). Однако важно понимать, что при определенных условиях эта «гарантия» может быть нарушена:

• Виртуализация и клонирование: Если администраторы разворачивают базы путем клонирования образов виртуальных машин или ОС, существует риск, что на разных узлах будут генерироваться идентичные идентификаторы.
• РИБ (Распределенные информационные базы): Если одинаковые идентификаторы появились в разных узлах, при синхронизации с Центральной Базой произойдет конфликт, в результате которого один объект «затрет» другой. Если сообщения при такой синхронизации требуется отправлять регулярно по расписанию поверх стандартных планов обмена, настраивают автоматический обмен данными между базами 1С.

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

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

Уникальность внутри одного типа документа

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

Влияние режима разделения данных

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

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

Практические рекомендации по работе с GUID

Чтобы избежать проблем с «пропаданием» документов и дублированием данных, придерживайтесь следующих правил:

• Избегайте клонирования: Никогда не копируйте базы данных методом «простого копирования» файлов или образов дисков для использования в качестве независимых узлов обмена РИБ. Используйте штатные механизмы создания начального образа.
• Проверка через язык запросов: Если вам нужно проверить уникальность идентификаторов, помните, что GUID не является абсолютной функцией МоментВремени(). Это разные сущности.
• Анализ структуры СУБД: Если вы работаете с составными типами полей, учитывайте, что на уровне СУБД такое поле формируется из двух колонок: ссылки на тип и самого идентификатора. Это объясняет, почему в регистрах могут соседствовать записи с одинаковыми GUID, но разными типами регистраторов.

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