Проектування структури highload-блоків 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
8+Років на ринку900+Реалізованих проектів100+Розробників у штаті19+Партнерів
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Проектування структури highload-блоків 1С-Бітрікс
Середня
~2-3 робочих дні
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989
Показати більше робіт

Проектування структури Highload-блоків 1С-Бітрікс

HL-блок — це генератор користувацьких таблиць у MySQL/PostgreSQL поверх D7 ORM. Технічно HL-блок — це запис у b_highload_block, набір полів у b_user_field, і автоматично створювана таблиця hl_{XML_ID}. Нічого магічного — просто спосіб створити таблицю з типізованими полями через інтерфейс Бітрікс без написання SQL. Але саме від того, як ця структура спроектована, залежить, чи буде HL-блок працювати як швидкий довідник або перетвориться на вузьке місце.

Коли HL-блок, а коли інфоблок або власна таблиця

HL-блок замінює інфоблок там, де не потрібні розділи, SEO-поля (META_TITLE, META_KEYWORDS), preview/detail-зображення та вбудовані механізми публікації. Це довідники: бренди, країни, теги, одиниці виміру, характеристики для фасету.

HL-блок програє власній D7-таблиці (DataManager) коли:

  • Потрібні складені індекси (HL підтримує лише індекси по окремих полях через UF_*)
  • Потрібні зовнішні ключі та каскадні операції
  • Схема таблиці часто змінюється та потребує міграцій

У цих випадках правильніше створити клас, що наслідує \Bitrix\Main\ORM\Data\DataManager, і керувати таблицею через нього.

Типи полів HL-блоку та їх особливості

HL-блоки використовують систему користувацьких полів (UF_*). Доступні типи:

  • string / string_formatted — VARCHAR. Для імен, назв.
  • integer — INT. Для числових ідентифікаторів, сортування.
  • double — DECIMAL/FLOAT. Для цін, коефіцієнтів.
  • boolean — TINYINT(1). Прапори активності.
  • file — зберігає ID файлу з b_file. Для зображень у довідниках.
  • enumeration — прив'язка до b_user_field_enum. Для фіксованих статусів всередині HL-запису.
  • datetime / date — DATETIME / DATE.
  • iblock_element / iblock_section — прив'язка до елемента або розділу інфоблоку. Використовується з обережністю: створює неявний зв'язок між HL та інфоблоком.

Проблема поля типу iblock_element у HL-блоці: при видаленні елемента інфоблоку HL-запис не оновлюється автоматично — потрібен обробник події OnAfterIBlockElementDelete.

Індексування полів HL-блоку

За замовчуванням HL-блок створює таблицю лише з PRIMARY KEY по полю ID. Всі інші поля — без індексів. Якщо HL-блок використовується як довідник для фасетного індексу каталогу, додаткові індекси зазвичай не потрібні — фасет працює з b_iblock_{ID}_index, а не з HL-таблицею напряму.

Але якщо HL-блок використовується для зберігання операційних даних (історія дій, лог замовлень, записи бонусної програми) — індекси по полях вибірки критичні. Додаються вручну через SQL-міграцію:

ALTER TABLE hl_loyalty_history ADD INDEX idx_user_id (UF_USER_ID);
ALTER TABLE hl_loyalty_history ADD INDEX idx_date (UF_DATE);

Бітрікс не надає UI для управління індексами HL-таблиць — лише прямий SQL або скрипт міграції.

Кейс: HL-блок як заміна інфоблоку для B2B-каталогу

Дистриб'ютор електроніки. У каталозі 2 200 унікальних характеристик товарів (технічні параметри). Спочатку — властивості інфоблоку типу «Рядок», b_iblock_element_property містила 8 млн рядків.

Рішення: перевести довідникові характеристики на HL-блоки за доменами:

  • hl_tech_connectivity — інтерфейси підключення (USB-C, HDMI тощо)
  • hl_tech_resolution — роздільні здатності екранів та матриць
  • hl_tech_standard — стандарти (Wi-Fi 6, Bluetooth 5.2 тощо)

Кожен HL-блок: поля UF_NAME (VARCHAR 255), UF_XML_ID (VARCHAR 50, унікальний), UF_ACTIVE (boolean), UF_SORT (integer). Індекси по UF_XML_ID — додані вручну для швидкого пошуку при імпорті з 1С.

Результат: b_iblock_element_property скоротилася з 8 млн до 1.2 млн рядків (залишилися лише числові властивості). Фасетний індекс перестворюється за 8 хвилин замість 45.

Управління даними HL-блоку через D7

Робота з HL-блоком у коді — через \Bitrix\Highloadblock\HighloadBlockTable і динамічно створюваний клас:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($id)->fetch();
$entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock);
$dataClass = $entity->getDataClass();
$rows = $dataClass::getList(['filter' => ['UF_ACTIVE' => true]]);

Це стандартний патерн — його важливо закріпити в code style проєкту, щоб звернення до HL-блоків не розповзалися по шаблонах у вигляді SQL-запитів.

Склад роботи з проектування HL-блоків

  • Аналіз властивостей інфоблоків: виявлення кандидатів для переведення на HL
  • Проектування схеми полів кожного HL-блоку
  • Визначення стратегії індексування
  • Планування міграції даних з b_iblock_element_property
  • Документування: схема таблиць, призначення полів, зв'язки
  • Скрипти створення HL-блоків та первинного заповнення

Строк проектування: 2–5 робочих днів на кожні 10–15 HL-блоків залежно від складності предметної області.

1С Бітрікс презентація1С Бітрікс24 презентація1С Підприємство презентація