E-shop: aplikovanie zliav

Je tu niekto kto vyvijal vlastny e-shop(pre klienta a pod)?Riesim momentalne zlavy a ide o to ze system zliav je robeny tak, ze sa zlava aplikuje pred zobrazenim polozky. Tzn data sa natiahnu z db s povodnou cenou, prejde to logikou nejakych pravidiel a ak polozka alebo navstevnik tieto pravidla splnaju aplikuje sa zlava. Toto riesenie je velmi dobre z mnohych hladisk ale nastava tu jeden obrovsky problem: radenie produktov podla ceny. Kedze zlava podlieha pravidlam pre jej aplikovanie a miesto jej aplikovania je az pred samotnym zobrazenim polozky, ak si navstevnik e-shopu usporiada polozky podla ceny, tak sa mu polozky zobrazia podla cien v db, tzn. bez vplyvu zlavoveho systemu. Toto spravanie som si vsimol aj na inych e-shopoch/rieseniach a moja otazka je co s tym? Kedze katalog produktov je strankovany, tak nie je mozne prbehnut pravidlami vsetky produkty a nanovo ich preusporiadat. Na druhu stranu aplikovat zlavy priamo do databaze je 'nemozne' kedze pravidla su dynamicke a ovplyvnuje ich mnoho veci(kategorie, vyrobca, datum, cena, skaldove zasoby, predajnost a samozrejme aktualny navstevnik). Tak by ma zuajimalo, ty ktory ste uz toto riesili, k comu ste sa dopracovali? Osobne si viem predstavit nechat to tak ako to je, ale z hladiska prevadzkovatela tak moze prist o mnoho objednavok, lebo navstevnici by nevedeli ze nejaky produkt na 5. strane katalogu na ktoru sa nedostali maju za 50% z ceny a nic si neobjednaju napr.Je toto jeden z tyhc problemov pre ktore neexistuje vhodne riesenie alebo mi nieco unika?

Nikdy jsem tohle neřešil v praxi, ale napadá mě řešení. Stáhněte z DB celou aktuální kategorii, uložte ji do pole objektů (nebo pole polí pokud nepíšete OOP), na to pole aplikujte slevy a pak teprve seřaďte a vyfiltrujte z něj požadovanou stránku. To pole můžete třeba uložit do session a kontrolovat, jestli už není stažené, aby se data nemusela stahovat pokaždé znovu.

Polem objektů bych to neřešil, při velkém počtu produktů na shopu je to příliš velká zátěž. Řešením pro počet produktů kolem 5000, nemáte-li výkonný server, je výpočet přímo v DB dotazu, pro případ řazení podle ceny je nutno seřadit joiny a ORDER BY tak, aby došlo k co největší redukci hodnot a co nejmenšímu vyčerpání paměti, pokud se jedná o shop s nepříliš velkým počtem položek.Druhá možnost, a tu bych asi preferoval, je tato, neboť stejně by se to vyřešit muselo i pro exporty zboží pro porovnávače: napsat speciální dotaz, který vypočte koncovou cenu a uloží ji pro každý produkt do speciálního sloupce. Ale opravdu to řešte SQL dotazem. Tento dotaz nebude trvat déle než vteřinu při 100000 produktech a značně si tím ulehčíte a urychlíte i export XML. Je to rozhodně několikanásobně rychlejší než data sbírat a zapisovat v cyklu pro každý produkt samostatným požadavkem na DB.Tuto předkešovanou cenu používejte jen pro exporty a pro řazení na shopu, jinak ne. Pro případy, kdy něco upravíte a zapomenete překešovat a vyexportovat. Porovnávače a řazení špatnou cenu snes, mít jinou cenu ve výpisu kategorie a jinou v detailu produktu už pak vypadá docela blbě :)

Bez popsání té logiky dostaneš jen polovičaté odpovědi. Nejsnažnější řešení je, kategorie zákazníka a plošná sleva? Je to tak, že logika je v tom, zjistit co je to za zákazníka a podle toho dostane slevu? Jestli ano, tak to řeší zbytečně, seřazení podle původních cen bude odpovídat i zlevněným.

2 double: Ano, pokud je to takto, tak ano, řazení bude vždy odpovídat řazení podle jakési základní ceny navedené v tabulce. V tom případě netřeba cache. Nicméně předpokládal jsem, že pokud to má jinak napsané inteligentně, tedy dají se dělat cenové akce na jednotlivé produkty a ještě různými způsoby výpočtu, pak je to, co uvádím, zřejmě optimální. Vyzkoušeno to mám na relativně velkém počtu položek a je zvolen kompromis s ohledem na spotřebu času v součtu a logiku použití. Zpočátku jsem se taky kešování chtěl vyhnout, ale vzhledem k tomu, že cache se tvoří cca vteřinu dvě i pro obrovský počet produktů, tak mi to přijde optimální. Navíc když je to v cache, vyhne se tak možnému přetížení do budoucna, kdyby stoupl traffic a složité procesy při výpisu mu souběžně zatěžovaly více vláken. Výpis v kategorii, i filtrovaný, bude vcelku rychlý. Skript s dotazem na seřazené produkty v kategorii při cca 100000 produktech bude trvat tak do 0,2 vteřiny, pokud tam nebude mít nějaká jiná zvěrstva.Myslím, že obecně vzato jeden z největších problémů českých e-shop systémů je neschopnost programátorů formulovat složitější DB dotazy. Řešení s jednoduchými dotazy, kde se pak zbylá data sbírají následně v cyklech, se vyskytuje až nehezky často. Přitom vyhodnocení téhož jediným dotazem ušetří někdy až vteřiny času.

mmm.edia tvoje riesenie je nepouzitelne, kedze ako som pisal, vypocet zlavy sa pocita v skripte(presnejsie nie je to mozne vypocitat priamo v db) a najme zlavy su dynamicke a zavisia od vela faktorov, ktore sa skratka nedaju riesit prepocitanim dopredu a ulozenim do db pre neskorsie radenie podla tychto prepoctov. Obavam sa ze naozaj pre toto neexistuje ine riesenie nez mat usporiadane produkty podla originalnej ceny.

Na druhou stranu, už jste někdy někdo použili v eshopu řazení podle ceny? - podle mne je to naprostá zbytečnost, maximálně tak filtr, ale ten už se dá aplikovat pouze v aplikační logice

2 node: To řešení je použitelné :) Já ho v systému mám a odezva výpisu v kategorii při 100k položkách je max 0.2 vteřiny bez zapnuté HTML cache, prostě se jedná o celkovou dobu běhu skriptu od inicializace systému po $smarty->display(). Ceny jsou v systému vypočítávány několika způsoby a jejich základ se vyhodnocuje dynamicky, ale přímo v DB dotazu. Nemluvím zde o jednořádkových dotazech, mám tam dotazy i na 30 řádků s JOINY přes 10 tabulek, včetně CASE a IF. Ceny mohou být vypočítávány marží (skupiny marže), nebo cenovým rozpětím (cenová pásma+součinitel), dále pak je možno mít uloženu pevnou cenu bokem (časově platnou od do, pro cenovou skupinu zákazníka), dále pak se vyhodnocuje součinitel cenové skupiny zákazníka a navíc ty cenové skupiny se ještě dělí na zákaznické a dealerské - liší se pro ně způsob výpočtu prodejní ceny, dealerský se odvíjí od nákupky, zákaznický počítá s vyhodnocením od základní prodejní ceny nereg.zákazníka). Přesto je to dost rychlé a cache sloupec se používá pro řazení pro výpis produktů. v podstatě na nic jiného není.V detailu produktu pak mohou být ceny ovlivněny neomezeně parametry, ale volby zákazníka na základní řazení nemají vliv. Jinak co se týká těch dlouhých DB dotazů, jsou opravdu několikanásobně rychlejší než vyhodnocování v cyklech po získání dat. MySQL umožňuje podmínkování a výpočty v podstatě stejně dokonalé jako PHP samotné, čili co lze řešit na úrovni DB, tak bych tak fakt řešil.Každopádně uznávám, že každý systém je jiný a fakt nedokážu posoudit jádro, které neznám. Snažil jsem se jen pomoci.