21.12.2017 16:57:02
Грузить свойства без нуменклатуры не выйдет. Мне даже в голову не приходило пытаться
|
|
|
|
21.12.2017 22:25:42
Вот что Битрикс ответил после недельной переписки:
- проблема не распространенная и вообще не типовой случай... "Обычно такая задача решается разделением на инфоблоки (по разделам или по типам). Каких-то штатных средств нет для ускорения продукта при таком количестве свойств." "Прочитайте статью наших специалистов по производительности: Особенное внимание уделите пункту "Неправильная структурная организация инфоблоков". Я думаю, что часть вопросов пропадёт. Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию." В самой статье ничего нового, а по этой теме привожу отрывок - "Неправильная структурная организация инфоблоков Пожалуй, это наиболее распространенная проблема — встречается в 90% проектах (а Битрикс сказал, что не типичная проблема). Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много. При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё." |
|
|
|
22.12.2017 10:38:52
|
|||
|
|
22.12.2017 11:11:00
Подготовил ссылки на темы по данной проблеме, может кому то полезно будет:
1. Как хранить большое количество характеристики товара? - 2. Каталог тормозит от большого количества свойств - 3. Организация инфоблока с большим количеством элементов - 4. Значения свойств элементов инфоблоков - какой вариант самый оптимальный? - 5. Максимальное количество свойств инфоблоков ограничено? Не сохраняются настройки инфоблока. - 6. При создании свойства выдается ошибка - 7. Битрикс тормозит при большом количестве свойств - 8. Битроник: 2-е архитектуры торгового каталога на выбор! - |
|
|
|
27.12.2017 11:40:02
Вы пробывали хранить часть свойств(не фильтруемых) одной строкой как текстовое описание ? У меня экономия на этом до 10к(95%) свойств.
|
|
|
|
27.12.2017 16:13:56
|
|||
|
|