сразу отмечу неправильное видение Битрикса:
проблема в компоненте bitrix:catalog*. По сути весь интернет магазин завязан на нем и поддерживает он только один инфоблок
стандартный компонент - это контроллер, который показывает возможности работы с API Битрикса (модулями).
минус стандартных компонентов: они сделаны под различные задачи, т.е. параметров там много, каждый параметр, это объем данных и обработка. итоговый массив данных содержит много не нужной информации.
Можно создать разделы в ручную, но еще кучу компонентов завязано на этом компоненте.
Компоненты завязаны, когда они являются комплексными. т.е. в одном компоненте вызывается другой. Ничего не мешает вызывать компоненты по раздельности.
Highload блоки, но как понял для этого нужно под себя что-то переписывать, ведь они просто хранят информацию и просто реализовать через них поля нельзя
Highload-блок это отдельная таблица в базе данных и связать их с инфоблоками не состовляет проблем, в инфоблоке есть поле справочник, которое показывает как можно связать, но не обязательно использовать именно его, можно создать свое поле, или проще написать обработку связи в компоненте.
Инфоблоки лучше использовать, когда есть необходимость использования стандартных полей инфоблока или функционал завязанный на них, например модуль торгового каталога (именно модуль), если из стандартных полей используется минимум, и сущность не обрабатывается, а только привязывается куда-либо, то проще использовать HighLoadBlock т.к. они достаются из базы одним запросом.
в ручную делать костыли?
когда делаешь костыли, в итоге сайт обрабатывает стандартный функционал(включая не нужный в данном решение) и сверху еще твои костыли, что приводит к большой нагрузке а иногда и вообще к решению "битрикс-г****", чтобы такого не было, достаточно написать свои компоненты, которые узко-направленно настраиваются и обрабатывают только необходимую информацию используя API битрикса.
Ответ на вопрос "Как лучше спроектировать структуру сайта":
для начала необходимо расписать в тз весь функционал сайта, расписать связи, а затем уже обдумать куда лучше закидывать то или иное поле. 3000 свойств, это свалка, в любом случае есть необходимость раскидать, даже просто для наведения порядка и удобства в редактирование.
Если трафик магазина более 1000 в сутки, рекомендую писать собственные компоненты, на собственных компонентах можно добиться и поддерживать более высокую скорость работы, чем на стандартных.
