Как в 1С реализовать связь товаров «один ко многим» и что лучше выбрать?

При проектировании структуры метаданных в платформе 1С:Предприятие разработчики часто сталкиваются с задачей связать один товар с группой других товаров. Это могут быть комплектующие, сопутствующая номенклатура (кросс-продажи), аналоги, варианты упаковки или спецификации. В зависимости от бизнес-логики и объемов данных связь может быть как строго иерархической («один ко многим», 1:N), так и перекрестной («многие ко многим», M:N).

Рассмотрим подробнее три основных архитектурных варианта реализации таких связей в платформе 1С, проанализируем их особенности, ограничения по производительности и критерии выбора.

Вариант 1. Табличная часть справочника номенклатуры

Самый простой и прямолинейный способ — добавить табличную часть непосредственно в справочник Номенклатура (например, табличная часть СопутствующиеТовары с реквизитом Товар типа СправочникСсылка.Номенклатура).

Разберем особенности и ограничения данного подхода:

1. Блокировки и работа с памятью: В объектной модели 1С табличная часть считывается и записывается в СУБД целиком вместе с объектом. Если у позиции номенклатуры привязано большое количество строк, при каждом открытии и сохранении карточки товара возрастает нагрузка на оперативную память и дисковую подсистему.
2. Конкурентный доступ: Невозможно параллельно изменять состав связанных позиций одного товара из разных сеансов — блокируется весь элемент справочника целиком.
3. Ограничение связи: Реализует структуру, где состав привязан строго к конкретной позиции. Если один и тот же набор товаров нужно привязать к десяткам позиций, данные придется дублировать в каждой карточке.

Когда применять: Табличные части отлично подходят, когда количество связанных строк невелико (до нескольких десятков), они редактируются вручную пользователем непосредственно в карточке товара и не требуют независимого обновления фоновыми заданиями или внешними интеграциями.

Вариант 2. Подчиненный справочник (связь через стандартный реквизит «Владелец»)

Второй вариант — создать отдельный справочник (например, ВариантыКомплектацииНоменклатуры) и подчинить его справочнику Номенклатура через настройку подчинения в конфигураторе.

Проанализируем технические особенности подчиненных справочников:

1. Строгая иерархия 1:N: Подчиненный элемент ссылается строго на одного владельца через стандартный реквизит Владелец. Реализовать связь «многие ко многим» без дублирования элементов подчиненного справочника здесь нельзя.
2. Каскадные операции: Платформа берет на себя поддержание ссылочной целостности: при установке пометки на удаление на элемент-владелец платформа автоматически помечает на удаление все подчиненные ему элементы.
3. Отображение в интерфейсе: В формах и динамических списках встроен механизм автоотбора по владельцу, что упрощает разработку интерфейсной части.
4. Собственный состав реквизитов: Каждый подчиненный элемент является самостоятельным объектом, может иметь свои коды, наименования, реквизиты и даже собственные табличные части.

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

Вариант 3. Независимый регистр сведений

Наиболее универсальное и производительное решение для связывания номенклатурных позиций — использование независимого регистра сведений (например, СопутствующиеТовары или АналогиНоменклатуры).

Структура регистра обычно проектируется следующим образом:

1. Измерение ОсновнойТовар: тип СправочникСсылка.Номенклатура.
2. Измерение СопутствующийТовар: тип СправочникСсылка.Номенклатура.
3. Ресурсы и реквизиты (опционально): приоритет показа, процент скидки, коэффициент совместимости.

Выясним преимущества регистра сведений:

1. Поддержка связи «многие ко многим» (M:N): Один и тот же товар может выступать как основным, так и сопутствующим для неограниченного числа других позиций без дублирования мастер-данных.
2. Параллельность записи и транзакционная безопасность: Запись набора записей регистра блокирует только диапазон соответствующих измерений, не накладывая исключительную блокировку на сам элемент справочника Номенклатура. Это позволяет внешним интеграциям или фоновым алгоритмам массово обновлять связи в фоновом режиме.
3. Периодичность: Регистр сведений можно сделать периодическим. Это позволяет хранить историю связей или задавать сопутствующие товары с определенной даты.
4. Высокая скорость выборки: Измерения регистра автоматически индексируются СУБД. В запросах выборка связанных данных через соединения (ЛЕВОЕ СОЕДИНЕНИЕ) выполняется максимально эффективно.

Посмотрим на пример выборки сопутствующих товаров запросом к регистру сведений:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	СопутствующиеТовары.СопутствующийТовар КАК Товар,
    |	СопутствующиеТовары.Приоритет КАК Приоритет
    |ИЗ
    |	РегистрСведений.СопутствующиеТовары КАК СопутствующиеТовары
    |ГДЕ
    |	СопутствующиеТовары.ОсновнойТовар = &ОсновнойТовар
    |УПОРЯДОЧИТЬ ПО
    |	Приоритет УБЫВ";

Запрос.УстановитьПараметр("ОсновнойТовар", ВыбранныйТоварСсылка);
РезультатЗапроса = Запрос.Выполнить();

Критерии выбора подходящей структуры данных

Подведем итог и сформулируем правила выбора:

1. Выбирайте табличную часть, если связей немного, они уникальны для каждого товара, не требуют версионирования по датам и редактируются исключительно вручную оператором в форме элемента.
2. Выбирайте подчиненный справочник, если дочерняя запись представляет собой отдельную сложную сущность с набором собственных реквизитов и жестко привязана к жизненному циклу одного владельца (строго 1:N).
3. Выбирайте регистр сведений, если требуется реализовать отношение «многие ко многим» (сопутствующие товары, аналоги), обеспечить высокую производительность при параллельной записи или хранить периодические данные.