Свой тип инфоблока и свойства в Битрикс: что выбрать

В 1С-Битрикс можно завести отдельный тип инфоблока для каталога курсов, а внутри него — свойства «Уровень», «Преподаватель» и «Дата старта». Но тип не задаёт схему данных: он лишь группирует инфоблоки в административной части. Если смешать эти задачи или выбрать свойства без учёта будущих фильтров и обменов, каталог быстро обрастёт дублями и нестабильными связями.

Что именно вы настраиваете

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

Свойство описывает данные элемента: строку, число, дату, список, связь с элементом или разделом. Выбирайте его не только по тому, как значение вводят в форме, но и по тому, как его будут искать, фильтровать, обновлять и передавать во внешние системы.

Справочник — здесь это набор повторно используемых значений с собственной структурой, например список преподавателей с именем, должностью и фотографией. Это отличается от простого списка, где у каждого варианта обычно есть только подпись и идентификатор.

Тип инфоблока отвечает на вопрос «где это лежит в админке», а свойство — «какие данные хранятся у элемента». Не пытайтесь решить обе задачи одним выбором.

Создать через интерфейс или поддерживать кодом

В проектах на «1С-Битрикс: Управление сайтом» встречаются два практических подхода. В первом структуру создаёт администратор через панель управления. Во втором настройки включают в поставку проекта и применяют при развёртывании или обновлении. Второй вариант обычно связан с системой миграций или собственными установочными скриптами; конкретный механизм зависит от проекта и его окружения.

Смешанный вариант тоже возможен: разработчик создаёт и меняет структуру через поставку, администратор наполняет справочники и элементы через панель. Важно заранее разделить ответственность. Если администратор вручную добавит свойство, а код ожидает другую схему, ошибка может проявиться не при сохранении элемента, а в фильтре или импорте.

Как выбрать свойство под данные

Смотрите на поведение значения, а не только на форму ввода. Например, «Статус курса» обычно удобнее хранить как список с ограниченным набором вариантов, чем как свободный текст: иначе появятся «активен», «Активен» и «идёт набор». Но если у статуса есть собственные поля, история или отдельные права доступа, простого списка может не хватить.

• Строка — для короткого текста без отдельного поведения: внешнего кода, примечания, названия. Не используйте её для значений, которые нужно строго выбирать из общего набора.
• Число или дата — для значений, которые участвуют в сортировке, сравнении или календарной логике. Текстовое представление даты плохо подходит для надёжной сортировки и фильтрации.
• Список — для небольшого контролируемого набора вариантов, например формата обучения. Проверьте, кто и как будет менять варианты: изменение подписи не должно неожиданно менять смысл уже сохранённых данных.
• Привязка к элементу — когда значение должно ссылаться на отдельную сущность, например преподавателя или производителя. Так можно хранить общую карточку и использовать её в нескольких местах, но нужно учитывать выборку связанных элементов и доступы.
• Привязка к разделу — когда элемент должен указывать на раздел структуры инфоблока. Это не замена произвольной связи между сущностями: сначала проверьте, что модель разделов действительно отражает предметную область.
• Справочник — когда варианты имеют собственные атрибуты и должны использоваться в нескольких местах. За гибкость платите дополнительной настройкой и необходимостью поддерживать справочник.

Множественное значение включайте только тогда, когда элемент действительно может иметь несколько значений. Это влияет на форму редактирования и на обработку данных в запросах и обменах. Если у курса один преподаватель, множественная привязка не делает модель лучше — она лишь разрешает лишнее состояние.

Когда какой подход выбирать

Нужен ли отдельный тип

Создавайте тип, если инфоблоки образуют отдельную группу, для которой полезны собственные названия, административная навигация или настройки. Не создавайте новый тип ради одного свойства: для этого достаточно настроить свойства нужного инфоблока. И не используйте тип как замену разделам каталога — это разные уровни организации.

Нужна ли отдельная сущность

Если значение повторяется в разных инфоблоках и у него есть собственные данные или жизненный цикл, рассмотрите отдельный инфоблок либо справочник на основе highload-блока. Если вариантов мало и у них только название, список проще сопровождать. Разница станет заметной, когда потребуется массово менять данные, строить фильтр или передавать значения в интеграцию.

Highload-блок — механизм Битрикс для хранения структурированных записей, который часто используют для справочников и больших наборов значений. Он не является автоматической заменой свойствам инфоблока: способ чтения и редактирования данных в проекте нужно продумать отдельно.

Что ломается после запуска

Самые дорогие ошибки обычно не в создании поля, а в изменении уже используемой структуры.

• Переименовали код свойства. Шаблоны, компоненты, фильтры и обмены могут искать старый код. Перед изменением проверьте, где он используется, и тестируйте на копии данных.
• Удалили свойство, которое ещё читает код. Страница может перестать выводить данные, а импорт — записывать их. Удаление в админке не заменяет поиск зависимостей.
• Сделали справочник списком, а затем понадобились атрибуты. Если варианту теперь нужны сортировка, внешний идентификатор или дополнительные поля, миграция потребует продумать соответствие старых значений новым записям.
• Разные среды получили разные настройки. На тесте поле есть, на продакшене его нет — или наоборот. Для проекта с регулярными релизами описывайте структуру в повторяемом процессе поставки и сверяйте результат на каждой среде.

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

Что делать дальше

Составьте короткую схему сущностей: какие инфоблоки нужны, какие данные принадлежат элементу, а какие повторяются и должны жить отдельно. Для каждого свойства запишите тип, одиночное оно или множественное, кто меняет значения и где они используются. Затем решите, где будет храниться схема: только в административной панели или в повторяемом процессе поставки. Перед релизом проверьте создание, редактирование, фильтрацию и импорт на тестовой среде.

В этой статье речь о моделировании инфоблоков и свойств; настройка конкретных компонентов каталога и индексация умного фильтра — отдельные задачи.