[ALG] Cookie trail via recursie of querystring?

[Reveller]

Ik zit al een tijdje mijn hersenen te kraken op het volgende.

Stel: ik maak een online winkel en een van de vereisten is een cookie crumb trail trail op elke pagina binnen de site. Op internet kom ik grofweg twee manieren tegen waarop winkels deze trail samenstellen:

1. je leest een uniek id uit, uit de querystring en haalt recursief uit de database het pad naar dat artikel of die categorie op. Hier heb ik al eerder een vraag over gesteld. Het ging toen met name over het (naar mijn zin te) grote aantal queries wat dit veroorzaakt. Inmiddels heb ik - dankzij de antwoorden die gegeven werden - veel meer kennis over cachen, etc. maar dat is afftopic.

2. zie bijvoorbeeld default.aspx?sf=ec&dept=ec0015&cat=ec0017&subcat=ec0019&prev=hp!sf!dept!cat. (URL). Dat is een wezenlijk andere URL dan bij de eerste manier, waarbij de URL bijvoorbeeld http://www.hsn.com/cnt/browse?id=ec0019 is.

Via de eerste manier zou ik mijn recursieve functie laten beginnen met id = ec0019, hier de parent van opvragen (ec0017), daar de parent weer van opvragen (ec0015), en tenslotte daar weer de parent van opvragen (ec). Vervolgens loop ik deze resultaten om de trail te krijgen:

code:

Electronics (naam van id=sf) > Cameras (naam van id=ec0015) > 
Digital Cameras (naam van id=ec0017) > 2 Megapixels (naam van id=ec0019)

Maar HSN.com bouwt deze trail als het ware op in de querystring, zoals je kunt zien. Mijn vraag is waarom zij dit doen?! In eerste instantie zou je kunnen denken "dan hoef ik het niet meer uit de database te trekken en dat scheelt queries" maar dat argument gaat volgens mij niet op. Om de id-nummers uit de querystring (ec, ec0015, ec0017 en ec0019) om te zetten naar namen, moet je alsnog gangen naar de database maken:

code:

SELECT name FROM categories WHERE id=ec
SELECT name FROM categories WHERE id = ec0015
SELECT name FROM categories WHERE id = ec0017
SELECT name FROM categories WHERE id = ec0019

Kan iemand mij vertellen wat - behalve voorkeur - argumenten zijn om deze methode te gebruiken? Zie ik iets over het hoofd en is het weldegelijk efficienter?

P.S: aan de querystring te zien, gaat de boom op HSN nooit dieper dan 4 lagen: sf (storefront), dept (department), cat (category) en soms nog subcat (subcategory). Zoals ik het begrijp krijgen zij dus een probleem als ze ooit dieper willen gaan, zoals electronics > computers > desktops > apple > G2 series > dual processors bijvoorbeeld, maar dat beschouw ik als off-topic. Het gaat mij om de efficiency van de aanpak.

Ik hoop dat iemand mij een onderscheid kan aangeven.

[Verwijderd]

Reveller schreef op 11 januari 2004 @ 14:59:

code:

SELECT name FROM categories WHERE id=ec
SELECT name FROM categories WHERE id = ec0015
SELECT name FROM categories WHERE id = ec0017
SELECT name FROM categories WHERE id = ec0019

Dit zou je tot 1 query kunnen combineren:

code:

SELECT id, name FROM categories WHERE 
id IN('ec', 'ec0015', 'ec0017', 'ec0019')

Dat is het enige voordeel wat ik in deze constructie kan zien.

[ Voor 3% gewijzigd door Verwijderd op 11-01-2004 20:33 ]

[Reveller]

Dat is natuurlijk wel prettig; van 4 queries terug gaan naar 1. Ik begreep alleen dat MySQL minder stabiel is wanneer het op subqueries aankomt. Kan iemand hierover een uitspraak doen met betrekking tot dit geval?

Ik kan me voorstellen dat ik liever per bezoekers 4 queries aanroep waarvan ik weet dat ze voor MySQL een eitje zijn, dan dat ik 1 query aanroep welke bij een zwaardere load spaak gaat lopen (...caching buiten beschouwing latende).

RobinVR geeft hier het - waarschijnlijk enige - voordeel van een soortgelijke querysting aan. Ik zou nog graag willen weten: is dat een gebruikelijke manier van werken of prefereren jullie de eerste methode (zie openingstopic) met 4 uit recursie ontstande queries?

Ik hoop op nog een aantal reakties

[Apollo_Futurae]

Als ik het goed begrijp wil je een boomachtige structuur in een relationele database opslaan. Hier is veel over te vinden, o.a:

[rml][ mysql] boomstructuur[/rml]
[rml][ mysql][ php] tree[/rml]