Антон: меня по крайней мере бесит кэш - это просто УГ. Т.е. грубо говоря если товаров за 5 тысяч, вы столкнетесь с жуткими тормозами. С SEO есть проблемы дубликатов, лечится все жуткими костылями, те же фильтры с правильными чпу тоже не сделаешь без костылей.
1) по умолчанию в методе возвращаем 0 (бесплатная доставка) или false (Вообще не выводить)
2) Получаем данные от api (Событие или ввод адреса или отдельная кнопка) и сохраняем данные о результате в бд.
3) getOrderShippingCost дергаем данные все время из бд, не затрагивая api
Наверное туда записывают ответ от api как то. И идет проверка. Т.е. пока апи не сработало, данные не дергаются. А тут идет своеобразное кэширование результата выполнения api.
Человек уже хринит данные с помощью Eav. Ему охота ускорить выборку, а не делать хранение проще. Для фасетного поиска лучше использовать специальные поиск. Движки или хотя бы добавить дополнительную что бы не плодить 100 JOINов design-pattern.ru/patterns/single-table-inheritanc...
Как зачем индексировать? Если запесей миллион, Вы хотите перебрать их все? Индекс помог бы это избежать, но тут его не получиться применить, т.к. требуются дополнительные вычисления
в престе чуть больше возможностей из коробки, порог вхождения побольше => модулей меньше и они дороже, но зато качественней. Общий функционал у них примерно одинаковый.
1. Конечно на пользовательской части использую только массивы. Что бы кэш использовать и для безопасности. Но работать с массивами не удобно, т.к. логику не реализуешь.
Конечно могут. Попробуй сейчас спарсить, к примеру яндекс маркет. Сразу нечего не получится, нужно наличие js у парсера и эмуляция поведения пользователя. Но обойти всегда все можно, главное - это цена, которая будет при этом затрачена.
