Проектирование пользовательских свойств инфоблоков 1С-Битрикс

Почему ломается каталог при росте номенклатуры

Каталог на 200 позиций работает быстро на любой конфигурации. Проблемы начинаются на 5–10 тысячах: страница категории грузится секунды, фильтры по характеристикам отваливаются по таймауту, а выгрузка из 1С растёт с каждой синхронизацией. Причина почти всегда одна — стихийное проектирование свойств инфоблоков, когда характеристики добавляли по мере появления задач, без общей модели данных.

Типичный сценарий: под каждый новый параметр заводили отдельное свойство, часть — множественным, часть — строкой, часть — привязкой к справочнику. Появляются дубли характеристик — «Цвет» и «Цвет товара», «Мощность, Вт» и «Мощность (Вт)», — а вместе с ними разросшаяся структура каталога, где на одном товаре висит несколько десятков значений, половина из которых пустая. Выборка товаров по такому инфоблоку идёт через множество соединений таблиц свойств, и время ответа растёт не линейно, а кратно числу фильтров в запросе.

Ошибки проектирования инфоблоков редко видны на старте — они проявляются, когда номенклатура вырастает в разы, а маркетингу нужен ещё один срез фильтра. Переделка на живом каталоге дороже: нужно переносить значения, сохранять адреса страниц и не потерять позиции в поиске. Поэтому модель свойств проектируют заранее — под текущий ассортимент и под то, как он будет расти.

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

Схема свойств инфоблоков: типы, привязки, режимы хранения

Типы свойств и их влияние на выборку

Одиночное свойство хранится одной строкой в основной таблице значений — выборка по нему идёт напрямую, без промежуточных соединений. Множественное свойство раскладывается в отдельные записи, и при выводе списка элементов это превращается в дополнительный JOIN на каждое свойство в фильтре. Практическое правило: множественность оправдана там, где реально нужен набор значений (галерея, несколько телефонов, теги), и вредна там, где бизнес-логика допускает одно значение — «на всякий случай множественное» даёт кратную просадку на каталогах от нескольких тысяч позиций.

Привязка к разделам и торговым предложениям

Привязка свойств к разделам позволяет держать разный набор характеристик для разных категорий: у ноутбуков — диагональ и тип матрицы, у аксессуаров — совместимость. Без неё карточка обрастает пустыми полями, а формы редактирования становятся нечитаемыми для контент-менеджера. Свойства торговых предложений наследуются от товара иначе — их стоит проектировать отдельным набором, иначе фильтр по цвету или размеру начинает работать через товар, а не через предложение, и выдача ломается.

Режимы хранения: когда какой

1С-Битрикс даёт готовые механизмы под каждый режим, но выбор между ними — это решение по нагрузке, а не по удобству редактора. На проектах с каталогом от десятков тысяч позиций мы фиксируем режим хранения до начала наполнения: смена схемы на живом каталоге требует миграции значений и переиндексации поиска.

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

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

1. Аудит инфоблоков. Снимаем карту: какие инфоблоки есть, какие свойства реально задействованы в компонентах, шаблонах и обмене с 1С, а какие висят мёртвым грузом. Фиксируем типы, множественность, привязку к разделам и связи между свойствами.
2. Схема свойств. Проектируем целевую структуру под задачи бизнеса: единые справочники вместо дублей, осмысленные коды свойств, разделение полей под фильтры и под хранение. Схема согласуется до начала работ — правки на этом этапе дешевле, чем после миграции.
3. План миграции свойств. Раскладываем переход на шаги с сохранением работоспособности сайта: где нужен перенос значений, где — переиндексация, где — временное дублирование полей на время перехода.
4. Настройка инфоблоков. Собираем структуру на стенде, прогоняем обмен с 1С, проверяем выгрузки, фильтры и разделы. Только после сверки данных переносим на прод.
5. Проверка на реальных данных. Сравниваем выборки до и после, контролируем полноту переноса и корректность связей между разделами и элементами.
6. Регламент сопровождения. Передаём правила: как заводить новые свойства, какие типы допустимы, кто согласует изменения, чтобы структура не расползлась снова.
7. Передача документации. Схема, карта свойств и регламент остаются у команды заказчика — правки дальше вносятся без археологии по коду.

Такой порядок снимает главный риск — потерю данных при перестройке структуры. Опишите задачу: вернёмся с оценкой и планом по вашему проекту.

Чем отличается свойство инфоблока от характеристики торгового предложения?

Свойство инфоблока — это атрибут самого товара: артикул, бренд, страна производства, состав. Характеристика торгового предложения — это то, чем отличаются варианты одной позиции: цвет, размер, объём, комплектация. Различие свойств и характеристик проявляется в момент, когда покупатель выбирает конкретный вариант: свойства описывают карточку целиком, характеристики — каждое торговое предложение внутри неё. Если вынести цвет в свойство товара, у вас получится отдельная карточка на каждый оттенок, и каталог распухнет на порядок.

Ключевой критерий — по какому признаку покупатель выбирает и фильтрует. Признак, который сужает выбор внутри одной модели, идёт в торговое предложение. Признак, который описывает сам товар и одинаков для всех его вариантов, остаётся свойством инфоблока. Ошибка в проектировании свойств инфоблоков стоит дорого: неверная развилка приводит к дублям карточек, ломает сквозную выгрузку характеристик в 1С и заставляет переписывать фильтры заново.

Фильтрация по свойствам и по характеристикам работает по-разному. Свойство инфоблока фильтруется напрямую по товарам, характеристика — через торговые предложения, и умный фильтр должен уметь собирать значения из обоих уровней. Если цвет лежит в свойстве, а размер — в характеристике, фильтр «цвет + размер» будет возвращать пустые выборки, пока логику не сведут в один запрос по двум инфоблокам.

Отдельная боль — обмен с 1С. Характеристики торговых предложений выгружаются из справочника номенклатуры иначе, чем свойства товаров: у них своя структура, свои торговые предложения и свои правила сопоставления. Когда признак ошибочно оставили свойством, выгрузка характеристик приходит пустой или дублируется, и менеджеры правят каталог руками после каждого обмена.

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

Кейс: перестройка свойств каталога без остановки продаж

Каталог на 40 000 позиций жил на «плоской» схеме: 60+ свойств в одном инфоблоке, часть характеристик продублирована в торговых предложениях, часть — в описании товара текстом. Фильтр по трём параметрам собирал выборку 4-6 секунд, а менеджеры заводили новые позиции с разной разметкой — отсюда расхождения в характеристиках у одинаковых товаров. Останавливать магазин на переиндексацию было нельзя: доля заказов с сайта в сезон слишком высока.

Разбили каталог на связанные инфоблоки: базовый товар, торговые предложения и отдельный справочник характеристик со своими свойствами. Дубли схлопнули в справочник, а на карточке оставили только те свойства, что участвуют в фильтре и выгрузках. Миграцию свойств без простоя провели в четыре шага: подготовили новую структуру рядом со старой, перенесли данные пакетами с логированием расхождений, переключили шаблоны и компоненты фильтра, затем удалили устаревшие свойства. Каждый этап откатывался: пока новая схема не прошла сверку, трафик шёл на прежние шаблоны.

Результат по метрикам: выборка по фильтру сократилась с 4-6 секунд до 0,8-1,2, доля дублей характеристик упала примерно на 70%, а время заведения новой позиции менеджером уменьшилось вдвое — часть полей подтягивается из справочника. Реорганизация инфоблоков затронула и обмен с 1С: выгрузка стала предсказуемой, потому что сопоставление свойств теперь идёт по стабильным кодам, а не по названиям.

Работали на штатном ядре платформы и её механизмах кеширования — без сторонних надстроек, которые пришлось бы сопровождать отдельно. 1С-Битрикс даёт для этого готовые инструменты: связанные инфоблоки, управляемый кеш и пошаговые агенты, ими и закрыли перестройку.

Если у вас каталог растёт, а фильтр и выгрузки тормозят — опишите задачу, вернёмся с оценкой и планом перестройки свойств.

Совместимость, откат и доступы: что обсудить до старта

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

Что если потребуется вернуть всё как было? Откат изменений закладываем заранее: перед правками снимаем дамп инфоблока и структуры свойств, ведём изменения отдельными шагами, чтобы каждое можно было отменить точечно, без отката всего сайта. Доступы к инфоблокам разграничиваем по ролям — контент-менеджер, интегратор, администратор — с журналом действий, чтобы правки структуры не терялись и были отслеживаемы.

На руки заказчик получает:

• карту совместимости свойств инфоблоков с текущими шаблонами и обменом;
• схему пользовательских свойств с кодами, типами и назначением;
• регламент доступов к инфоблокам по ролям;
• инструкцию по откату изменений и точки сохранения;
• документацию по свойствам для контент-менеджеров;
• протокол проверки обмена с 1С после правок.

Опишите вашу задачу — вернёмся с оценкой и планом работ по вашему проекту.

Сроки этапов внедрения новой схемы свойств

Сроки зависят не от объёма кода, а от количества инфоблоков, связей между ними и того, насколько активно контент-менеджеры правят данные в момент миграции. Ниже — ориентир для типового проекта: каталог с торговыми предложениями, несколько разделов контента и одна интеграция с учётной системой. Для крупных порталов с десятками инфоблоков и складскими остатками диапазоны сдвигаются вправо пропорционально числу сущностей.

Длительность аудита напрямую определяет, сколько времени уйдёт на миграцию: если на этом этапе находятся свойства-дубли и поля, которые нигде не выводятся, проектирование сразу сокращает объём переносимых данных. График работ по инфоблокам строим так, чтобы миграция шла блоками — сначала каталог, затем контент, затем интеграционные выгрузки, — и каждый блок можно было проверить отдельно, не останавливая сайт целиком.

Указанные сроки — ориентировочные и не привязаны к календарным датам: они пересчитываются после аудита, когда виден реальный объём сущностей и качество текущих данных. Если часть инфоблоков уже описана корректно, соответствующие этапы проходят быстрее.