При работе с самописными конфигурациями 1С иногда встречаются архитектурные решения, которые кажутся инородными для платформы. Одной из таких ситуаций является использование типа данных УникальныйИдентификатор (GUID) для организации связей между объектами (например, в иерархии оргструктуры или привязке сотрудников к должностям) вместо стандартных ссылочных типов данных. В этой статье мы подробно проанализируем, почему такой подход является "антипаттерном", и подготовим мощную аргументацию для рефакторинга системы.
Давайте разберем ситуацию, когда в регистре сведений иерархия строится на единственном измерении с типом УникальныйИдентификатор. На первый взгляд кажется, что это универсальный первичный ключ. Однако в экосистеме 1С это решение отсекает 90% возможностей платформы. Рассмотрим основные технические риски, которые мы можем использовать в качестве доводов для руководства.
1. Нарушение контроля ссылочной целостности
Это самый критичный аргумент. В 1С стандартный механизм "Тестирование и исправление" (ТиИ) умеет находить и восстанавливать "битые ссылки". Если объект (подразделение или сотрудник) будет физически удален из базы, система, использующая ссылки, предупредит об этом или очистит поле. В случае с GUID платформа "не знает", что это значение является ссылкой на другой объект. Проанализируем последствия: база постепенно заполнится "мертвыми" идентификаторами, которые никуда не ведут, а отчеты начнут выдавать пустые строки или ошибки без возможности автоматического исправления.
2. Невозможность обращения "через точку"
Рассмотрим, как усложняется работа программиста. При использовании стандартных ссылок (например, СправочникСсылка.Сотрудники) мы можем в любом месте кода или запроса получить данные связанного объекта:
// Стандартный подход (ссылки)
ПодразделениеНаименование = РегистрСведений.Оргструктура.Должность.Владелец.Наименование;
// Подход через GUID (текущая ситуация)
// Придется сначала найти объект в базе по идентификатору
СсылкаНаДолжность = Справочники.Должности.ПолучитьСсылку(Новый УникальныйИдентификатор(ИдентификаторИзРегистра));
Если Не СсылкаНаДолжность.Пустая() Тогда
ПодразделениеНаименование = СсылкаНаДолжность.Подразделение.Наименование;
КонецЕсли;
Выясним причину неэффективности: такой код в разы объемнее, сложнее в поддержке и медленнее в исполнении, так как требует дополнительных обращений к базе данных там, где платформа могла бы использовать кэш.
3. Проблемы производительности и индексации
В СУБД (MS SQL, PostgreSQL) стандартная ссылка 1С хранится как оптимизированное двоичное поле _IDRRef. Когда мы строим связи через GUID, особенно если он хранится в строковом виде, индексы работают менее эффективно. При выполнении тяжелых отчетов по оргструктуре СУБД будет вынуждена делать сложные соединения (JOIN), что приведет к деградации производительности при росте количества записей.
Если теоретические доводы не помогают, перейдем к практической демонстрации. Проанализируем несколько стратегий поведения.
Попробуем наглядно показать руководителю хрупкость системы. Для этого выполним следующие шаги на копии базы:
НайтиСсылки() не находит связей в этом модуле, что делает невозможным безопасное удаление данных пользователями.Вместо того чтобы просто критиковать, создадим альтернативу. Разберем, как это сделать:
Спроектируем на копии небольшую схему, где связи реализованы через справочники и регистры со ссылочными типами. Проанализируем скорость написания запроса для построения иерархии в обоих вариантах. Разница в объеме кода и наглядности схемы запроса будет лучшим аргументом. Покажем, что в вашем варианте отчет строится одним простым запросом, а в текущем — требует сложной обработки в цикле или "ручных" соединений.
Выясним стратегические планы компании. Если планируется синхронизация с 1С:Зарплата и Управление Персоналом, использование GUID станет непреодолимым препятствием. Стандартные механизмы обмена данными (EnterpriseData, КД 2.0 или КД 3.0) ориентированы на ссылочную целостность. Попытка передать "самодельные" связи во внешние системы потребует написания огромного количества кастомных правил конвертации, что увеличит стоимость внедрения в разы.
Посмотрим на ситуацию со стороны корпоративной этики, учитывая, что вы только сменили место работы:
Резюме: Использование GUID вместо ссылок в 1С лишает систему типизации, контроля целостности и удобства разработки. Наилучшая тактика — подготовить прототип, доказывающий преимущество ссылочной модели, и акцентировать внимание на невозможности будущих интеграций и высокой стоимости поддержки текущего решения.