Проектування структури інфоблоків 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 робочих днів залежно від кількості інфоблоків та складності предметної області.