Nevíte náhodou někdo, jak je optimalizovaný algoritmus na filtry zboží? Zakliknu třeba že chci televize značky Sony, a hned mi u checkboxu pro úhlopříčku vyjede počet výsledků, pokud ten filtr pro úhlopříčku zakliknu taky. Je to rychlé, takže nepředpokládám že by dělali query a count pro každý nezakliknutý checkbox. Zároveň taky nepředpokládám že mají předpočítané všechny kombinace, těch by bylo fakt hodně. Nebo je na to třeba nějaká šikovná stromová struktura?
vola sa to "faceted search" a ano, robia query na vsetky filtre, nie je to take zlozite/narocne ako sa na prvy pohlad moze zdat. staci mat dobre navrhnutu schemu a zvladne to mysql ako nic, netreba ziadne komplikovane grafove db alebo elastic search a podobne.
Díky, ten termín mi chyběl. Už to studuju.
heuraka používá elasticsearch a cachuje výsledky v memcache, co si pamatuji. U dospělých sql databází můžeš používat výrazy jako select count(uhlopricka=XX), count(uhlopricka=YY), které jsou na úrovni db vykonány velice rychle, bohužel mysql/mariadb neumí.
Faceted je stromová struktura, používá třeba zmíněný elestic, resp. sorl, který je uvnitř. Udělat tohle v mysql není sranda, povětšinou se končí spoustou malých dotazů, které se mohou v redisu/memcached uchovávat než jednom velkém s joiny.
Kategorie jsou většinou statické, u řady projektů jsem dělal předpočítávání, skončí se sice s 100M záznamy v db (jako např. u jednoho velkého knihkupectví), ale pořád to je rychlejší na dotazy a provoz než to vyhledávat s joiny či zanášet do stacku novou technologii (elastic či jinou db).
Elastic umi navic i perfektni agregace, takze tyhle veci se tam resi fakt rychle - a ano, Heureka jede na Elasticu
