Проектирование структуры инфоблоков 1С-Битрикс

Проектирование структуры инфоблоков 1С-Битрикс

Инфоблок — центральная единица хранения контента в Битрикс. Плохо спроектированный инфоблок через год превращается в проблему: фильтр не работает, импорт из 1С ломает данные, запросы к b_iblock_element_property генерируют полный перебор. Хорошо спроектированный — работает без изменений структуры 5–7 лет.

Типы данных и выбор типа свойства

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

• Строка — текстовые значения без повторений. Не подходит для справочников (бренд, страна, материал), потому что не индексируется фасетом и создаёт дубли в b_iblock_element_property.
• Число — для числовых значений, участвующих в фильтре по диапазону (цена, вес, мощность).
• Список — для фиксированного набора значений (статусы, категории размеров). Значения хранятся в b_iblock_property_enum.
• Справочник (HL-блок) — для динамических справочников с большим количеством значений (бренды, страны, теги). Хранит INT-ключ вместо текста, индексируется фасетом.
• Файл — изображения и документы. Для каталога товаров дополнительные изображения лучше хранить именно здесь, а не в DETAIL_PICTURE и PREVIEW_PICTURE, если их больше двух.
• Привязка к элементам — связь между элементами инфоблоков. Используется для связанных товаров, аксессуаров, комплектов.

Структура типов инфоблоков

Тип инфоблока — это группировка, не имеющая технического значения, но критичная для управляемости. Правило: один тип инфоблока = один домен данных. «Каталог», «Статьи», «Баннеры», «Справочники» — правильная группировка. «Сайт» как единственный тип для всего — антипаттерн.

Для интернет-магазина типовая структура типов:

• catalog — инфоблоки каталога товаров и торговых предложений
• content — новости, статьи, FAQ
• references — справочники (используемые как источник для свойств типа «Список», если не HL-блоки)
• landing — лендинговые блоки, баннеры

Разделы инфоблока: глубина иерархии

Разделы (b_iblock_section) хранятся в нативном дереве Битрикс. Практическое ограничение: глубина вложенности более 5–6 уровней создаёт проблемы с хлебными крошками, ЧПУ и навигацией. Если бизнес требует более глубокой иерархии (например, запчасти для оборудования: производитель → модель → серия → узел → деталь) — рассматривается замена иерархии свойствами с фильтрацией вместо навигации по разделам.

Множественные свойства и производительность

Множественное свойство хранит несколько значений в b_iblock_element_property — по одной строке на каждое значение. 10 000 элементов × свойство с 5 значениями = 50 000 строк в таблице только для этого свойства. При множественных свойствах-справочниках фасетный индекс обрабатывает их корректно, но нагрузка при пересоздании индекса выше.

Правило: если свойство редко бывает заполнено (заполнено у 10% элементов) — пустые записи не хранятся, что снижает объём таблицы. Если свойство заполнено у всех элементов и редко меняется — рассмотреть перенос в отдельную HL-таблицу через DataManager.

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

Платформа объявлений о продаже и аренде недвижимости. Изначальное решение: один инфоблок «Объекты» с 40 свойствами, включая строковые адрес, район, метро.

Проблемы через 8 месяцев:

• Фильтр по метро работал как текстовый поиск (LIKE), а не по индексу
• Дубли значений: «м. Арбатская», «Арбатская», «арбатская» — три разные записи
• Поиск по радиусу от метро невозможен без геокоординат

Реструктурированная схема:

• catalog тип: инфоблок «Объекты» + инфоблок «Жилые комплексы»
• HL-блок hl_metro с полями: UF_NAME, UF_LINE, UF_LAT, UF_LON — 342 записи вместо текстовых значений
• HL-блок hl_district — районы с привязкой к городу
• Свойства «Площадь», «Этаж», «Этажность» — тип «Число» для фильтра по диапазону
• Свойство «Метро» — справочник (HL), множественное (несколько станций)

Фасетный индекс после реструктурирования: создаётся за 3 минуты на 85 000 объектов, фильтр по метро и типу — 0.15 секунды.

Что включает проектирование структуры инфоблоков

• Определение списка инфоблоков и типов инфоблоков
• Проектирование схемы свойств с выбором типов
• Решения по HL-блокам для справочных свойств
• Проектирование иерархии разделов
• Определение свойств, участвующих в фасетном индексе
• Документирование: схема в табличном формате для каждого инфоблока
• Оценка объёма данных и прогноз нагрузки на b_iblock_element_property

Срок: от 3 до 10 рабочих дней в зависимости от количества инфоблоков и сложности предметной области.