Vypsání položek a podpoložek dle váhy (levelu)

Sir Tom:
Můžeš si vybrat z následujících řešení:
* vybrat z databáze vše a řešit to na úrovni aplikace
* změnit strukturu uložení dat (hledat traverzování kolem stromu)
* změnit databázi na nějakou, která umí rekurzivní dotazy

Pokud vím, na úrovni MySQL to při stávající struktuře nejde elegantně vyřešit.

Teorie je např. na http://interval.cz/clanky/metody-ukladani-stromovych-dat-v-relacnich-databazich/
Prakticky potom nejlépe na http://php.vrana.cz/traverzovani-kolem-stromu-prakticky.php

Je to časný problém. Začátečníci vymyslí ukládání parent id (nebo to radí na nějakém známém webu?) a pak nevědí, jak dál...

Alphard:
„Je to časný problém. Začátečníci vymyslí ukládání parent id (nebo to radí na nějakém známém webu?) a pak nevědí, jak dál...“

Nelíbí se mi, že z toho příspěvku vyznívá, že použití parent_id je špatný návrh databáze. Podle mě návrh pomocí parent_id je ten správný a používání odkazovaného uložení je workaround, jak to řešit, že databáze nemá rekurzivní dotazy. Přijde mi to, jak ukládání počtu položek, kdyby databáze neuměla efektivně COUNT(*). Analogie funguje i v tom, že někdy může být 'méně pěkné' řešení lepší z důvodu optimalizace i v databázi, která umožňuje obě možnosti (a rozdíl nebude velký, ani lft, rgt ani ruční ukládání počtu položek jsem snad zatím z optimalizačních důvodů nepoužil).

TomášK:
„Nelíbí se mi, že z toho příspěvku vyznívá...“
Měl jsem si to asi odpustit :-), trochu jsem doufal, že právě zjistím příčinu.
99 % dotazů se tady týká MySQL a tazatelé s ním pracují, takže rekurzivní dotazy prostě nejsou k dispozici. Menší datové sady lze řešit rekurzivně s pomocí PHP, ale je jasné, že výkon klesá docela rychle. V dané situaci je traverzování kolem stromu asi nejlepší možnosti. Prostě denormalizace z praktických důvodů, nebudu stavět teoreticky dokonalou relační databázi, ze které nedostanu data (zřejmá nadsázka, nebrat doslova). Objektivní hodnocení jednotlivých metod je v odkázaném článku, včetně informací o tom, že přesunout uzly ve stromě není zrovna jednoduché.

Alphard:
„Menší datové sady lze řešit rekurzivně s pomocí PHP, ale je jasné, že výkon klesá docela rychle.“

Jen bych pro představu doplnil, že při té logice, která je uvedena v #1, je získání dat z databáze nepoužitelně pomalé už při 500 položkách - jde o sekundy.

Alphard:
Souhlasím, že pro MySQL je to zřejmě nejlepší řešení - jak říkáš, denormalizace z praktických důvodů.

Nepřekvapuje mě, že struktura s parent_id je to, co navrhují ti, co na tenhle problém zatím nenarazili. Jedná se o běžné použití cizího klíče, jen je cílová tabulka shodná se zdrojovou. Pokud někdo používá cizí klíče, je tohle přesně struktura, která ho napadne. Traverzování kolem stromu nenapadne při prvním použití snad nikoho - pokud si o ní nepřečte článek.

okolojdouci:
Uvedená čísla jsou zřejmě pro hodně pomalou implementaci. Zkusil jsem si napsat kod, který vygeneruje strom - pole s položkami (id, parent_id), zamíchá ho a poté vypíše tak, jako se vypisuje menu. Včetně vygenerování a setřídění to na 1000 položkách trvá 0.03s. Pro 50 000 položek to trvá ~1sec.

TomášK:
„Uvedená čísla jsou zřejmě pro hodně pomalou implementaci“

Uf, tak to se omlouvám. Netestoval jsem to nějak podrobně, skládám z toho menu, které se rozbaluje javascripem, tak ta prodleva může vznikat tam.