@pantaleone48

Много свойств в одном инфоблоке. Как лучше спроектировать структуру сайта?

В инфоблоке каталога уже более 3 тысяч свойств и необходимо добавить еще много новых. На текущей стадии уже появились проблемы с добавлением и сохранением. Как лучше спроектировать структуру сайта, чтобы избавиться от данной проблемы? В интернете много советов об разделении категорий на инфоблоки, но проблема в компоненте bitrix:catalog*. По сути весь интернет магазин завязан на нем и поддерживает он только один инфоблок. Можно создать разделы в ручную, но еще кучу компонентов завязано на этом компоненте. Видел решение через Highload блоки, но как понял для этого нужно под себя что-то переписывать, ведь они просто хранят информацию и просто реализовать через них поля нельзя, как я понял. Как быть в данной ситуации, разделять инфоблоки на категории и в ручную делать костыли?
  • Вопрос задан
  • 72 просмотра
Пригласить эксперта
Ответы на вопрос 2
@RuComMarket
Битрикс FullStack разработчик
сразу отмечу неправильное видение Битрикса:
проблема в компоненте bitrix:catalog*. По сути весь интернет магазин завязан на нем и поддерживает он только один инфоблок

стандартный компонент - это контроллер, который показывает возможности работы с API Битрикса (модулями).
минус стандартных компонентов: они сделаны под различные задачи, т.е. параметров там много, каждый параметр, это объем данных и обработка. итоговый массив данных содержит много не нужной информации.
Можно создать разделы в ручную, но еще кучу компонентов завязано на этом компоненте.

Компоненты завязаны, когда они являются комплексными. т.е. в одном компоненте вызывается другой. Ничего не мешает вызывать компоненты по раздельности.
Highload блоки, но как понял для этого нужно под себя что-то переписывать, ведь они просто хранят информацию и просто реализовать через них поля нельзя

Highload-блок это отдельная таблица в базе данных и связать их с инфоблоками не состовляет проблем, в инфоблоке есть поле справочник, которое показывает как можно связать, но не обязательно использовать именно его, можно создать свое поле, или проще написать обработку связи в компоненте.
Инфоблоки лучше использовать, когда есть необходимость использования стандартных полей инфоблока или функционал завязанный на них, например модуль торгового каталога (именно модуль), если из стандартных полей используется минимум, и сущность не обрабатывается, а только привязывается куда-либо, то проще использовать HighLoadBlock т.к. они достаются из базы одним запросом.
в ручную делать костыли?

когда делаешь костыли, в итоге сайт обрабатывает стандартный функционал(включая не нужный в данном решение) и сверху еще твои костыли, что приводит к большой нагрузке а иногда и вообще к решению "битрикс-г****", чтобы такого не было, достаточно написать свои компоненты, которые узко-направленно настраиваются и обрабатывают только необходимую информацию используя API битрикса.

Ответ на вопрос "Как лучше спроектировать структуру сайта":
для начала необходимо расписать в тз весь функционал сайта, расписать связи, а затем уже обдумать куда лучше закидывать то или иное поле. 3000 свойств, это свалка, в любом случае есть необходимость раскидать, даже просто для наведения порядка и удобства в редактирование.
Если трафик магазина более 1000 в сутки, рекомендую писать собственные компоненты, на собственных компонентах можно добиться и поддерживать более высокую скорость работы, чем на стандартных.
Ответ написан
@Firsov36
full-stack web developer
Все не стандартные решения Битрикс не поддерживает и тут приходят на помощь специалисты. Возможно Ваша проблема не в том, что компонент или сервер не могут обработать Ваши тысячи свойств, а в том, что не правильно используете эти свойства, чего-то недопонимаете.

То, что можно раскидать свойства по инфоблокам, тоже вариант, опять же надо знать Вашу "кухню" нужно ли это и Битриксом это поддерживается, например bitrix:catalog.main компонент, в котором используются bitrix:catalog.

Highload блоки быстрые, свойство инфоблока можно привязать к Highload блокам как привязка к Справочнику. Или же написать свой функционал.

в ручную делать костыли
- не костыли, а свое решение задачи))
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы