Через 2 года после запуска типичного интернет-магазина на Битрикс инфоблок каталога выглядит так: 60 свойств, из которых 20 не заполнено ни у одного товара, 15 — строковые с повторяющимися значениями, 8 — с названиями вроде PROP_123 или MY_FIELD. Это результат органического роста без проектирования. Мы видим такие кейсы постоянно — и знаем, как предотвратить хаос. Если вам нужен порядок в свойствах — спроектируем схему под ключ за 5–7 дней. Добавить свойство в Битрикс легко — в три клика. Удалить или переименовать без потери данных и поломки импорта из 1С — значительно сложнее.
Как избежать хаоса в свойствах инфоблока?
Непродуманная схема свойств приводит к проблемам: фасетный индекс не строится, обмен с 1С валится, а разработчики тратят часы на дешифровку PROP_47. Опыт показывает: экономия времени на старте оборачивается неделями рефакторинга. Средняя экономия на рефакторинге — от 400 часов работы разработчика. Гарантируем, что спроектированная нами схема служит годами без переделок.
Как правильно выбрать символьный код свойства?
Символьный код (CODE) должен быть латиницей, уникален в рамках инфоблока и совпадать с полем в 1С (если есть обмен). Практические правила:
- Только латиница, цифры, подчёркивание
- Верхний регистр:
BRAND,COLOR,WEIGHT_KG - Составные названия через подчёркивание:
TECH_PROCESSOR,TECH_RAM_GB - Группировка по префиксу:
SEO_H1,BADGE_NEW
| Вариант | Пример | Рекомендация |
|---|---|---|
| Верхний регистр, префикс | CATALOG_ARTICLE |
✅ Для единообразия |
| Нижний регистр, без префикса | article |
⚠️ Допустимо, но менее читаемо |
| Набор символов | PROP_47 |
❌ Запрещён — нечитаем |
| Смешанный регистр | ArticleNumber |
❌ Не рекомендуется из-за кейс-инсенситивности |
Символьный код после создания изменить нельзя без прямого обращения к b_iblock_property. Поэтому правильное именование на старте критично.
Фасетные свойства и их настройка
Обязательность (IS_REQUIRED) нужно проставлять осознанно. Если свойство обязательно, а импорт из 1С его не передаёт — элемент не сохранится, обмен упадёт. Правило: обязательность лучше контролировать на форме ввода или в бизнес-процессе, а не на уровне инфоблока, если данные приходят извне. Потери от ошибок импорта — до 100 тысяч рублей за каждый инцидент.
Не все свойства должны участвовать в фасетном индексе. Стратегия деления на категории:
| Категория | Примеры | Тип данных | Фасетный индекс |
|---|---|---|---|
| Фасетные | Бренд, цвет, размер | Список, HL-блок | ✔️ |
| Информационные | Описание, состав | Строка, HTML | ❌ |
| Системные | ID интеграции, флаг | Строка, число | ❌ |
Когда использовать множественные и вычисляемые свойства?
Множественное свойство создаёт по строке в b_iblock_element_property на каждое значение. Оправдано для цветов, тегов, совместимости. Не оправдано «на всякий случай» — увеличивает объём таблицы без пользы.
Иногда в свойство пишут рейтинг или минимальную цену. Если данные читаются часто, а обновляются редко — хранение в свойстве с кешем оправдано. В остальных случаях — вычислять в arResult.
Кейс из нашей практики: аудит и реструктуризация 78 свойств инфоблока
Магазин автозапчастей. Инфоблок «Каталог» с 78 свойствами. Задача — подготовить к обмену с новой конфигурацией 1С и включить фасетный индекс.
Аудит показал:
- 18 пустых свойств (ни одного заполненного значения)
- 12 строковых справочников (марка, модель) — кандидаты на HL-блоки
- 5 свойств с нечитаемыми кодами (
PROP_47,FIELD_2019) - 3 дублирующихся свойства
Результат после реструктуризации:
- 18 пустых свойств удалены (проверка на использование в коде)
- 12 свойств переведены на 4 HL-блока с миграцией данных
- Символьные коды переименованы через
b_iblock_property - Итоговый инфоблок: 45 свойств, 14 в фасетном индексе
Из практики: типовой аудит свойств занимает один рабочий день, а реструктуризация — до 7 дней в зависимости от объёма.
Этапы проектирования свойств
- Аудит текущей схемы (если есть) — выявление пустых, дублирующихся и нечитаемых свойств.
- Проектирование новой схемы — определение типов, кодов, обязательности, группировки.
- Распределение по категориям (фасетные, информационные, системные).
- Планирование HL-блоков для справочников.
- Документирование маппинга с полями 1С.
- Написание скриптов миграции и отката.
- Тестирование обмена и фильтрации.
Пример скрипта миграции для перевода свойства-списка в HL-блок
// Псевдокод: создание HL-блока, перенос данных, удаление старого свойства $hlBlockId = createHlBlock(['NAME' => 'Brands']); foreach ($oldValues as $value) { addElementToHl($hlBlockId, ['UF_NAME' => $value]); } updatePropertyType($propertyId, 'HL', $hlBlockId); Что входит в проектирование свойств
- Документация: схема свойств с кодами, типами, обязательностью, маппинг с 1С.
- Миграционные скрипты: для рефакторинга существующих данных.
- Доступы: к инфоблокам и HL-блокам для дальнейшей поддержки.
- Инструкция: по добавлению новых свойств в будущем (шаблоны кодов).
- Поддержка: 1 месяц консультаций после сдачи.
Сроки проектирования
От 3 до 7 рабочих дней для каталога до 100 свойств. Точная оценка — после аудита текущей структуры. Свяжитесь с нами, чтобы обсудить ваш проект и получить консультацию. Закажите проектирование сейчас — избежите затрат на рефакторинг.
CommerceML — стандарт обмена, которому должна соответствовать структура свойств. Документация 1С-Битрикс по свойствам — официальный справочник.