← К списку

Мы часто сталкиваемся с вопросом, почему в системах 1С, особенно при интеграции с другими продуктами, для хранения уникальных идентификаторов объектов из внешних систем (например, ERP, ЗУП КОРП или УХ) не создается отдельный справочник-посредник. Вместо этого, эти идентификаторы, часто представленные в виде УИД (UUID/GUID), хранятся напрямую в реквизитах объектов. Давайте вместе разберемся в причинах такого подхода, проанализируем его преимущества и особенности, опираясь на опыт сообщества 1С и общие принципы проектирования баз данных.

Бесшовная интеграция и универсальные идентификаторы (UUID/GUID)

Одной из ключевых причин, по которой 1С использует прямую передачу и хранение УИД, является необходимость обеспечения бесшовной интеграции с другими информационными системами. Когда функционал, например, из Документооборота 3 должен взаимодействовать через API с крупными корпоративными системами, такими как 1С:ERP, 1С:ЗУП КОРП или 1С:Управление холдингом, критически важно иметь универсальный, глобально уникальный идентификатор.

Рассмотрим подробнее, почему UUID (Universally Unique IDentifier) или GUID (Globally Unique IDentifier) являются предпочтительным выбором для таких сценариев:

1. Глобальная уникальность: UUID разработаны таким образом, чтобы быть уникальными в пространстве и времени. Это означает, что идентификатор, сгенерированный в одной системе, будет гарантированно уникальным даже при объединении данных с десятками других систем без централизованной координации. Это крайне важно для распределенных систем и сложной интеграции.
2. Генерация на клиенте: UUID могут быть сгенерированы как на стороне базы данных, так и на стороне клиентского приложения. Это значительно упрощает логику клиентских приложений и позволяет сократить количество запросов к базе данных, поскольку не требуется обращение к серверу для получения уникального автоинкрементного номера.
3. Безопасность и скрытие информации: В отличие от последовательных числовых идентификаторов, UUID менее предсказуемы. Это может повысить безопасность системы, так как злоумышленникам гораздо сложнее угадать или перебрать идентификаторы других записей.
4. Масштабируемость: UUID идеально подходят для распределенных систем, архитектур на основе микросервисов и шардирования баз данных. В таких сценариях централизованный счетчик для автоинкрементных ID может стать «узким местом», замедляя систему.
5. Совместимость: UUID не привязаны к конкретной технологии баз данных, что обеспечивает высокую гибкость при выборе различных СУБД и упрощает взаимодействие между разнородными платформами.

Однако, мы также должны учитывать и некоторые недостатки использования UUID:

1. Размер и производительность: UUID занимают больше места (16 байт) по сравнению с целочисленными типами (4 или 8 байт). Это может привести к увеличению размера индексов и, потенциально, замедлить операции с базой данных, поскольку новые значения UUID могут попадать в любое место индекса, требуя дополнительных затрат на его обслуживание и фрагментацию.
2. Сложность: Генерация и обработка UUID может быть более сложной, чем работа с простыми числовыми идентификаторами.
3. Читабельность: UUID менее читабельны для человека, чем простые последовательные числа, что может усложнить отладку или ручной поиск данных.

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

Оптимизация производительности и минимизация "лишних" связей

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

На больших объемах данных, характерных для корпоративных систем, каждое дополнительное соединение может значительно увеличить время выполнения запросов и потребление системных ресурсов. Прямое хранение УИД в реквизите объекта позволяет избежать этого "лишнего" шага. 1С уже имеет внутренний механизм для работы с ссылками на объекты (например, СправочникСсылка.<имя>, ДокументСсылка.<имя>), которые по сути являются оберткой над УИД объектов 1С. Расширение этого принципа на внешние УИД является логичным и производительным решением.

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

Избегание проблем с составными типами и сложностью реляционных связей

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

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

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

Применение синтетических ключей (УИД) вместо естественных

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

Многие специалисты рекомендуют использовать синтетические ключи, и 1С в своей основе придерживается этого принципа, используя УИД как внутренний идентификатор. Почему?

1. Нестабильность естественных ключей: Естественные ключи могут меняться. Например, код валюты может быть изменен, или код страны может быть отменен, а затем снова введен с другим значением. Если бы мы использовали такие коды для прямых ссылок, изменение кода привело бы к нарушению целостности всех связанных данных.
2. Проблемы с уникальностью: Естественные ключи не всегда гарантируют глобальную уникальность. Например, в разных системах могут использоваться одинаковые коды для разных сущностей.
3. Периодичность: Для некоторых данных (например, курсы валют) может быть важна периодичность. Один и тот же код может иметь разные значения в разные периоды времени. Использование естественного ключа в этом случае становится очень сложным.

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

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

← К списку