Проектування користувацьких властивостей інфоблоків 1С-Бітрікс
Через 2 роки після запуску типового інтернет-магазину на Бітрікс інфоблок каталогу виглядає так: 60 властивостей, з яких 20 не заповнено жодним товаром, 15 — рядкові з повторюваними значеннями, 8 — з назвами на кшталт PROP_123 або MY_FIELD. Це результат органічного зростання без проектування. Додати властивість у Бітрікс легко — три кліки. Видалити або перейменувати без втрати даних і поломки імпорту з 1С — значно складніше.
Простір імен і угоди про іменування
Символьний код властивості (CODE) повинен відображати семантику, бути унікальним у рамках інфоблоку та збігатися з ідентифікатором у комплекті обміну з 1С (якщо він є). Практичні правила:
- Лише латиниця, цифри, підкреслення
- Верхній регістр:
BRAND,COLOR,WEIGHT_KG - Складені назви через підкреслення:
TECH_PROCESSOR,TECH_RAM_GB - Групування за префіксом для тематичних блоків:
SEO_H1,SEO_DESCRIPTION,BADGE_NEW,BADGE_SALE
Символьний код після створення властивості змінити не можна без прямого звернення до b_iblock_property — стандартний інтерфейс редагування коду не передбачений. Тому правильне іменування на старті є критичним.
Обов'язкові vs. опціональні властивості
Обов'язковість властивості (IS_REQUIRED) потрібно проставляти усвідомлено. Якщо властивість обов'язкова на рівні Бітрікс, а імпорт з 1С не передає її значення — елемент не збережеться, і обмін впаде з помилкою. Правило: обов'язковість краще контролювати на рівні форми введення або валідації в бізнес-процесі, а не на рівні інфоблоку, якщо дані надходять із зовнішньої системи.
Властивості для фасетного фільтра
Не всі властивості повинні брати участь у фасетному індексі. Фасет будується за властивостями типу «Список» та «Довідник» — додавання до індексу непотрібних властивостей збільшує час перестворення індексу та розмір таблиці b_iblock_{ID}_index.
Стратегія: властивості поділяються на три категорії:
- Фасетні — беруть участь у фільтрі користувача (бренд, колір, розмір, матеріал). Тип: Список або Довідник (HL-блок). Додаються до фасетного індексу.
- Інформаційні — відображаються на картці товару, не беруть участі у фільтрі (опис технології, склад, інструкція). Тип: Рядок, HTML/текст, Файл.
- Системні — використовуються програмно (прапори, ідентифікатори для інтеграцій). Тип: Рядок або Число. До фасету не додаються.
Множинні властивості: коли так, коли ні
Множинна властивість створює по одному рядку в b_iblock_element_property на кожне значення. Це виправдано для:
- Кольорів (товар випускається в кількох кольорах)
- Тегів (стаття належить до кількох тем)
- Сумісних моделей (запчастина підходить до кількох пристроїв)
Не виправдано, коли значення одне і множинність додана «про всяк випадок» — це збільшує обсяг b_iblock_element_property без користі.
Властивості-агрегати та обчислювані значення
Іноді у властивість інфоблоку записують обчислювані дані: рейтинг товару, кількість відгуків, «мінімальна ціна серед торгових пропозицій». Технічно це працює, але створює задачу синхронізації: при додаванні нового відгуку потрібно оновити властивість RATING через обробник події. Альтернатива — обчислювати значення в момент запиту через arResult компонента без зберігання у властивості. Що обрати — залежить від частоти читання vs. частоти зміни: якщо дані читаються 10 000 разів на добу і оновлюються 20 разів — зберігання у властивості та кеш виправдані.
Кейс: аудит і реструктуризація 78 властивостей інфоблоку
Магазин автозапчастин. Інфоблок «Каталог» з 78 властивостями. Задача — підготувати до обміну з новою конфігурацією 1С та увімкнути фасетний індекс.
Аудит показав:
- 18 властивостей не мали жодного заповненого значення за весь час
- 12 рядкових властивостей-довідників (марка, модель, виробник) — кандидати на HL-блоки
- 5 властивостей з нечитабельними кодами (
PROP_47,FIELD_2019) — неможливо зіставити з полями 1С без додаткового дослідження - 3 властивості-дублікати з різними кодами і однаковим змістом
Після реструктуризації:
- 18 порожніх властивостей видалено (після перевірки, що вони не використовуються в коді)
- 12 властивостей переведено на 4 HL-блоки
- Проведена міграція даних у HL-блоки, старі рядкові властивості очищені
- Символьні коди перейменовані через пряме оновлення
b_iblock_property - Підсумковий інфоблок: 45 властивостей, з них 14 у фасетному індексі
Склад роботи з проектування властивостей
- Аудит наявних властивостей (якщо рефакторинг)
- Проектування схеми властивостей з типами, кодами, налаштуваннями
- Розподіл властивостей за категоріями: фасетні / інформаційні / системні
- Планування HL-блоків для довідникових властивостей
- Документування маппінгу властивостей інфоблоку та полів 1С
- Написання скриптів міграції (при рефакторингу)
Строк: 3–7 робочих днів для каталогу до 100 властивостей.