Всего было предложено 2 варианта:
1. Перейти на инфоблоки 2.0 (у нас 300+ свойств, то есть нужно кастомизировать ядро)
2. Свойства товаров раскидать по категориям, а при выборке товара забирать только те свойства, которые прикреплены к категории товара.
Может кто-то пропустить эту задачу через призму собственного опыта и посоветовать решение?)
А почему надо кастомизировать ядро? Что вы получите в итоге? Рассматривался ли вариант, когда товар хранится в инфоблоке, свойства товаров разбиты по категориям и хранятся в hl-инфоблоках (справочниках), для привязки товара к свойствам используется отдельный hl-инфоблок (по id товара, например). Ну и при получении данных по товару из инфоблока идёт обращение к hl-инфоблокам. Соответственно, все sql-выборки из hl можно писать практически напрямую и и оптимизировать как угодно.
Кастомизация ядра в данном случае представляет собой просто смену условия в файле iblock_convert.php. Там проверка на количество свойств, если оно больше 50, то на инфоблоки 2.0 перейти нельзя. Есть идея увеличить это количество до 1000, например. Вариант с hl-блоками не рассматривали, спасибо, изучим вопрос в этом направлении
можно временно убрать проверку, перенести на инфоблоки 2.0 и вернуть обратно. но все эти эксперименты нужно конечно на тесте проводить
Обсуждают сегодня