RY
ещё у категорий есть свойства (картинки, количество товаров...) которые тоже придётся хранить в json и обновлять через Ж
Size: a a a
2020 March 15
A
Ок, с количеством товаров в узле меню подходит, чтобы строить его динамически через скл
RY
К сожалению по дефолту опенкарт так и делает
A
Скрыть и картинки, не вижу проблемы добавить в каждый узел свойства визибилити и Линк на картинку
A
Да его потом нужно постобработать на сервере, но зато прочитает быстрее.
RY
у нормальных людей запрос: показать все видимые категории
у тебя: получить гигабайт херни, распарсить, извлечь только нужное, заджойнить его с другими данными через Ж
у тебя: получить гигабайт херни, распарсить, извлечь только нужное, заджойнить его с другими данными через Ж
RY
и как апогей в итоге ты пытаешься решать уже говнокодом вещи которые давно и лучше за тебя решили ребята писавшие СУБД
A
Прочитать Джон из базы быстрее чем построить его склем
A
Если ты все переложить на базу ок, тогда склем все
A
Если у тебя простое меню с линками на страницы и возможностью скрыть, не вижу проблемы прочитать Джон
A
Если сложное, как ты описал, показать количество товара итд, то да скл лучше
RY
Andre
Прочитать Джон из базы быстрее чем построить его склем
Напиши крутой бенчмарк на 10000 категорий который покажет что выборка JSON из базы настолько выгоднее чем простой селект, что прям надо тратить время на весь этот колхоз или хотя бы этот диалог.
A
Простой селект с рекурсивным запросами?
A
Конечно выборка одного джсон дока будет быстрее
A
Пусть и на 10к категорий
RY
пока не вижу сложностей в селекте. пара джойнов - вообще не проблема в большинстве случаев
RY
Andre
Конечно выборка одного джсон дока будет быстрее
на сколько?
A
Да неважно, это чтение данных одно из одной строки
A
Без джинов итд
RY
если это будет не холодный старт, то ты вообще разницы не увидишь