Drobečková navigace

TUL: jestli pouzivas rekuzri, tak preci uplne stejne, ne? Na zacatku znas informace aktualni polozky menu.

1. Zjistim si id_rodice a jeho data.
2. Ulozim
3. Pokud ma nove ulozene take id_rodice, goto 1.

ninja
Pokud se tohle dělá častěji, je výhodnější si zvolit nějaký lepší způsob ukládání stromových dat, viz:
http://interval.cz/clanky/metody-ukladani-stromovych-dat-v-relacnich-d atabazich/
Na tohle bude asi nejlepší traverzování kolem stromu (Modified Preorder Tree Traversal algorithm), předpokládám, že přidání nové kategorie bude v poměru ke čtení seznamu kategorií spíše výjimečná událost.

Joker: s tim souhlasim, proto pisi "jestli pouzivas rekurzi".

Joker, ninja: osobně hlasuju pro starou dobrou klasiku parent_id - rekurze ... všechny ostatní metody obsahujou natrvrdo dopočítávaný prvky (a naprosto nadbytečný), což je nejoblíbenější zdroj chyb vůbec

MaxwellDemon
To je sice pravda, jenže s tímhle způsobem uložení jsou i takové maličkosti jako třeba:
- vypsat cestu k dané kategorii (právě ta drobečková navigace)
- vypsat strom kategorií
- určit, zda se určitý prvek nachází v určité kategorii
jsou docela problém.
Třeba s traverzováním stromu na každý ten úkol stačí jeden SQL dotaz.

Jinak jestli jsou ty sloupce "nadbytečné", to je otázka, protože je sice lze dopočítat z ostatních dat, ale není to právě jednoduché.
Třeba u traverzování stromu je pravda, že při každé změně struktury kategorií je potřeba "přeindexovat" strom. Nicméně zrovna u kategorií se to podle mě vyplatí- třeba já na svém webu dělal změnu struktury kategorií za toho půl roku co existuje asi třikrát, zatímco výběry z tabulky kategorií se dělají skoro na každé stránce několikrát.

Joker
nevim ... asi je to každému dle jeho potřeb a schopností ... já třeba ty rekurze nedělám v php vůbec a mám na to napsaný stored procedures přímo na databázi ... takže mi nic z toho do phpka neprobublává a volám vždycky akorát triviální select na tý proceduře (která mi vrací například i celou tu postupnou kaskádu pro jednotlivý id v jakýkoli úrovni) ... a v mým případě se ty kategorie (položky v menu) měněj způsobem, ze kterýho by mi časem zcela určitě hráblo, kdybych to měla pořád nějak růčo v databázi managovat ... a navíc tim generovat fakt zbytečný a navíc nebezpečný redundantní data

takže odpověď je jednoduchá ... za použití stored procedures ti na každej ten úkol stačí taky jeden jedinej naprosto triviální sql dotaz ... a i bez nadbytečných tvrdých dat ... jde jenom o čistej třívrstvej designovej návrh a jasný interfacy

MaxwellDemon
já třeba ty rekurze nedělám v php vůbec a mám na to napsaný stored procedures přímo na databázi
No ale jestli se z PHP volají přímo ty dotazy, nebo ta procedura, která je provede, přece nic nemění na tom, že databáze je musí zpracovat a tedy oproti traverzování stromu bude několikanásobně víc vytížená.

v mým případě se ty kategorie (položky v menu) měněj způsobem, ze kterýho by mi časem zcela určitě hráblo, kdybych to měla pořád nějak růčo v databázi managovat
Probůh, to ne- žádné takovéhle činnosti se samozřejmě nedělají v databázi ručně! Akorát se příslušně upraví funkce/metody na přidávání a přesouvání kategorií.

Traverzování stromu vlastně ve srovnání s ukládáním rodiče obrátí náročnost: zatímco při ukládání rodiče můžete velmi jednoduše strom upravovat, ale na vybírání potřebujete rekurzi, u algoritmu traverzování stromu naopak na výběr stačí jediný dotaz, ale na změnu stromu potřebujete většinou o dva dotazy navíc oproti ukládání rodiče (při ukládání rodiče jen ten dotaz co chcete udělat, při traverzování stromu pak ještě 2xUPDATE pro přenastavení levých a pravých indexů- ovšem i ty dva jednoduché UPDATE dotazy jsou výhodnější než rekurze, IMHO).

Joker
hmmmmm .... pochybuju, že bys to provedení rekurze na databázi, kde v tomhle připadě jde z hlediska performance o velice levnou proceduru na primárních klíčích v řádech několika milisekund na tisíce položek, vůbec poznal ... a jestli se z php volá postupně x dotazů na databázi v rámci rekurzivní php funkce nebo jestli se zavolá jedna procedura na databázi, která tu rekurzi provede přímo na databázi bez přenášení dat a vrátí jenom už celej hotovej výsledek, to už mi připadá z hlediska performance sakra rozdíl ... ovšem srovnání volání tý procedury s voláním dotazu na traverzovanej strom vyjde prakticky nastejno ... ten případnej rozdíl (if any) v rámci veškerých přenosů dat v rámci webový aplikace vůbec nepostřehneš ... a vyhneš se tý hromádce redundantních a zbytečných dat