Каталог из пяти тысяч товаров тормозит на каждом фильтре, обмен с 1С дублирует позиции, а добавить новую характеристику — трёхдневная эпопея с миграцией. Почти всегда корень таких проблем один: структуру данных каталога спроектировали наспех, «лишь бы заработало», и теперь платят за это каждый день. А переделать живой каталог куда дороже, чем продумать его на старте.
Эта статья — о том, как грамотно спроектировать структуру базы данных каталога на 1С-Битрикс: как устроены инфоблоки, когда нужны торговые предложения, как выбирать типы свойств, зачем highload-справочники и как согласовать всё это с умным фильтром, поиском и обменом с 1С. Материал опирается на нашу практику автоматизации проектов на 1С.
Коротко
- Каталог строят на инфоблоках — они интегрированы с фильтром, обменом и корзиной.
- Модель товар/торговое предложение нужна там, где у позиции есть варианты со своей ценой и остатком.
- Свойства проектируют по назначению и типу; фильтруемые характеристики — через списки и highload-справочники.
- Структуру согласуют с обменом 1С и прицеливают на фильтр, поиск и нагрузку заранее.
Почему структуру проектируют заранее
Структура данных каталога — это фундамент, на котором держится всё остальное: фильтр, поиск, карточка товара, обмен, корзина. Ошибка в фундаменте не видна сразу, но проявляется постоянно — тормозами, дублями, невозможностью добавить нужную функцию без переделки.
Ключевая причина проектировать заранее — стоимость изменений. Добавить свойство на живом каталоге просто, а вот сменить модель товаров, перенести данные между инфоблоками или переопределить типы свойств — трудоёмкая миграция с риском сломать обмен и фильтр. Чем больше каталог, тем дороже переделка.
Поэтому базовые решения — сколько инфоблоков, нужны ли торговые предложения, какие свойства и каких типов — принимают на старте, с запасом под рост номенклатуры. Это не перфекционизм, а экономия времени и денег на всю жизнь проекта.
Инфоблоки как основа каталога
В 1С-Битрикс каталог товаров строится на инфоблоках — это штатный механизм хранения структурированного контента. Для каталога он предпочтителен почти всегда, потому что связан со всей торговой инфраструктурой платформы.
Что даёт инфоблок каталога из коробки:
- Интеграцию с торговым каталогом. Цены, типы цен, остатки, единицы измерения.
- Умный фильтр. Компонент catalog.smart.filter работает по свойствам инфоблока.
- Обмен CommerceML. Выгрузка из 1С сама создаёт и наполняет инфоблоки.
- Корзину и заказ. Модуль «Интернет-магазин» работает с товарами инфоблока напрямую.
Соблазн заменить инфоблоки «своей быстрой таблицей» почти всегда ошибочен для каталога: вы потеряете фильтр, обмен и корзину и будете переписывать их вручную. Своя таблица на D7 хороша для служебных сущностей — логов, баллов, технических справочников, — но не для товаров. Подробнее про уместность D7 — в статье про D7 ORM в Битрикс.
Товары и торговые предложения
Ключевое проектное решение — нужна ли двухуровневая модель «товар + торговые предложения». Она разделяет карточку модели и её конкретные варианты.
| Уровень | Что это | Что хранит |
|---|---|---|
| Товар (родитель) | Карточка модели | Название, описание, общие свойства, изображения |
| Торговое предложение (SKU) | Конкретный вариант | Размер/цвет/фасовка, своя цена, артикул, остаток |
Пример: «Футболка» — товар, а «Футболка, синяя, M» и «Футболка, чёрная, L» — торговые предложения с собственными ценами, артикулами и остатками. Такая модель нужна, когда у позиции есть варианты, между которыми выбирает покупатель. Если вариантов нет (уникальная позиция), товар обходится без предложений — плодить их «на всякий случай» не нужно.
Свойства: типы и назначение
Свойства — то, из чего складывается вся полезная информация о товаре, и здесь легче всего наделать ошибок. Свойства проектируют сразу по двум осям: назначение и тип.
По назначению их удобно делить на группы:
- Характеристики для фильтра. То, по чему покупатель отбирает: бренд, цвет, размер, мощность.
- Служебные поля. Внешний код, артикул, привязки для обмена с 1С.
- Контентные поля. Описания, преимущества, комплектация для карточки.
По типу важно выбрать правильный: список или привязка к справочнику для повторяющихся значений, число для диапазонных характеристик, строка только там, где значение действительно произвольное. Ошибка типа дорого обходится: строковое свойство вместо списка замедляет фильтр и плодит разнобой написаний одного и того же значения.
Highload-справочники для значений
Когда значений свойства много и они повторяются у тысяч товаров, их выносят в highload-справочник — отдельную таблицу-словарь на D7. Свойство товара тогда хранит не строку, а ссылку на элемент справочника.
Зачем это нужно:
- Экономия и скорость. Вместо строки «Красный» у тысяч товаров — компактная ссылка; фильтр по справочнику быстрее.
- Единая точка правды. Переименовать бренд или добавить синоним можно в одном месте.
- Доп. поля значения. У элемента справочника бывают свои атрибуты — логотип бренда, код цвета, порядок сортировки.
Highload-справочники — типичный выбор для брендов, цветов, материалов, коллекций. Они особенно окупаются на больших каталогах, где одни и те же значения встречаются массово. Проектируя свойства, сразу решают, какие из них станут справочниками.
Разделы и навигация
Разделы инфоблока задают дерево каталога и во многом определяют навигацию и SEO. Здесь важен баланс: слишком плоская структура теряет товары, слишком глубокая утомляет пользователя и усложняет обмен.
- Разумная глубина. Обычно двух-трёх уровней достаточно; глубже — только при реальной необходимости.
- Свойства по разделам. Разные категории требуют разных характеристик — это решают привязкой свойств к разделам, а не отдельными инфоблоками.
- Согласование с 1С. Дерево разделов часто приходит из групп номенклатуры 1С, и структуру согласуют, чтобы обмен не плодил дубли.
- ЧПУ и SEO. Раздел — это URL и заголовки; структуру планируют с прицелом на продвижение.
Хорошее дерево разделов служит одновременно навигацией для покупателя, каркасом для фильтра и основой семантической структуры для SEO. Поэтому его проектируют вместе с ассортиментом, а не «как выгрузилось из 1С».
Структура под умный фильтр и поиск
Умный фильтр и поиск работают ровно настолько хорошо, насколько грамотно спроектированы свойства. Это главная причина проектировать структуру с прицелом на них.
- Отметьте фильтруемые свойства. У характеристик, по которым отбирают товар, включают участие в умном фильтре.
- Используйте списки и справочники. Фильтр по спискам и highload-справочникам работает быстро и без разнобоя значений.
- Числа — для диапазонов. Цена, мощность, вес как числовые свойства дают фильтр «от и до».
- Учтите предложения. Свойства вариантов (размер, цвет) фильтруют на уровне торговых предложений.
- Заложите точные поля для поиска. Артикул и код 1С — отдельные свойства под точный поиск, отличный от полнотекстового.
Про то, как отделить точный поиск по артикулу от полнотекстового и не потерять коды, у нас есть отдельный разбор в блоге. Здесь важно одно: если структура свойств продумана под фильтр и поиск заранее, оба работают быстро; если нет — их потом «натягивают» на неудобные данные.
Связь с обменом 1С
Каталог редко живёт сам по себе — товары, цены и остатки приходят из 1С через обмен CommerceML. Это значит, что структуру нельзя проектировать в отрыве от выгрузки: обмен сам создаёт и наполняет инфоблоки, и если структура сайта расходится с тем, что отдаёт 1С, обмен ломается или дублирует данные.
Что важно согласовать:
- Внешний код (XML_ID). Стабильный идентификатор, по которому обмен сопоставляет товары — он не должен «плавать».
- Артикул и коды. Как они передаются и в какие свойства ложатся.
- Привязку предложений. Как варианты связываются с товаром-родителем при выгрузке.
- Соответствие свойств. Какие характеристики из 1С в какие свойства инфоблока попадают.
Согласование структуры и правил обмена — обязательный этап проектирования, а не то, что чинят потом. Надёжность обмена во многом держится и на инфраструктуре: про окружение мы пишем в статье про хостинг и инфраструктуру BitrixVM.
Производительность и кэш
Хорошо спроектированная структура — это ещё и быстрый каталог. На больших объёмах разница между продуманной и небрежной моделью данных измеряется секундами загрузки.
- Правильные типы свойств. Списки и справочники индексируются и фильтруются быстрее строк.
- Индексируемые поля. Артикул, код и часто используемые в выборках свойства должны быстро находиться.
- Кэширование выборок. Списки, фильтр и карточки кэшируют, сбрасывая кэш при обмене.
- Разумное число свойств. Сотни редко используемых свойств тормозят фильтр — держите модель чистой.
Скорость каталога также сильно выигрывает от композитного сайта и грамотного кэша динамики. Как выстраивать выборки эффективно, мы разбираем в материале про D7 ORM в Битрикс — правильная структура и правильные запросы работают в паре.
Частые ошибки
- Строки вместо списков. Фильтруемые характеристики хранят как произвольный текст — фильтр тормозит, значения расходятся.
- Лишние торговые предложения. Двухуровневая модель там, где вариантов нет, — усложнение на ровном месте.
- Кастомная таблица вместо инфоблока. Потеря фильтра, обмена и корзины ради мнимой скорости.
- Плавающий XML_ID. Внешний код меняется при выгрузке — обмен плодит дубли.
- Слишком глубокие разделы. Пять уровней вложенности, где хватило бы двух.
- Структура без прицела на фильтр. Свойства заведены как попало, фильтр потом «натягивают».
- Нет запаса под рост. Модель не рассчитана на расширение ассортимента, каждый новый тип товара ломает схему.
Чек-лист проектирования
- Основа — инфоблоки. Каталог на инфоблоках, служебные сущности — на D7 по необходимости.
- Модель товаров определена. Решено, где нужны торговые предложения, а где нет.
- Свойства спроектированы. Разбиты по назначению, у каждого правильный тип.
- Справочники выделены. Повторяющиеся значения вынесены в highload-справочники.
- Разделы продуманы. Разумная глубина, свойства привязаны к разделам, согласовано с SEO.
- Фильтр и поиск учтены. Фильтруемые свойства отмечены, точные поля под поиск заведены.
- Обмен согласован. XML_ID стабилен, соответствие свойств 1С описано.
- Производительность заложена. Типы, индексы и кэш продуманы под объём каталога.
Вывод
Структура данных каталога — это фундамент магазина, от которого зависят фильтр, поиск, обмен и скорость. На 1С-Битрикс её строят на инфоблоках и торговом каталоге, вводя торговые предложения там, где есть варианты, тщательно проектируя свойства по назначению и типу и вынося повторяющиеся значения в highload-справочники. Всё это согласуют с умным фильтром, поиском и обменом с 1С.
Главный принцип — проектировать заранее и с запасом: переделать живой каталог дороже, чем продумать его на старте. Заложите правильную модель, стабильный обмен и прицел на нагрузку — и каталог будет быстрым и расширяемым годами. Если нужно спроектировать структуру под ваш ассортимент надёжно, доверьте это команде, которая ежедневно работает с автоматизацией продаж и склада на 1С.
