Složitější SQL dotaz

Nevěděl jsem, jak tento problém pojmenovat, ale jde o toto: Potřebuji mít více podkategorií (téměř někonečné vnořování), př - nemovitosti -> stavby -> rodinné domy -> a dalších třeba 10 podkategorií. Mám tabulku obsahující kategorie - id_kategorie, id_predchudce, nazev . id_predchudce značí, pod kterou podkategorii tato podkategorie patří (pokud je id_predchudce 0, jde o hlavní kategorie). aby si to šlo líp představit, nacpu tam nějaká data: INSERT INTO kategorie VALUES (1,0,'nemovitosti'); INSERT INTO kategorie VALUES (2,1,'stavby'); INSERT INTO kategorie VALUES (3,2,'rodinné domy'); Otázky: Jak vybrat z databáze údaje 'rodinné domy', 'stavby', 'nemovitosti', pokud známe číslo 3 - jako id_kategorie? 1. Lze to vůbec pokud neznáme, ve které úrovni se nachází naše známé id_kategorie? (jednou by dotaz vrátil jenom 'rodinné domy', 'stavby'; jindy 'jednopodlažní','rodinné domy', 'stavby', 'nemovitosti'), pomocí n dotazů to je jednoduché, ale pomocí jednoho nebo co nejméně? 2. Pokud víme například, že vždy budou mít sekce 3 úrovně, pak: (samozřejmě je nejvhodnější rozložit tabulku do 3 a bude pohoda, ale nechme to tak) je nějaký elegantnější způsob než za použití poddotazů? př. SELECT kategorie.nazev, kategorie.id_predchudce AS idp1, (SELECT kategorie.nazev FROM kategorie WHERE kategorie.id_kategorie = idp1 ) AS nazev2, (SELECT kategorie.nazev FROM kategorie WHERE kategorie.id_kategorie = ( SELECT kategorie.id_predchudce FROM kategorie WHERE kategorie.id_kategorie = idp1 ) ) AS nazev3 FROM kategorie WHERE id_kategorie =3 Nebo je snad rychlejší v PHP scriptu volat 3x jednoduchý dotaz na databázi? Není to nic jednoduchého, ale věřím, že se najde někdo, kdo bude vědět, co s tím. Za všechny odpovědi předem děkuji.

Dříve jsem na to používal rekurzivní funkce ale je to dost neohrabané, takže si myslím že ti pomůžu traverzování kolem stromu - jako mě. Vybrat potom nějakou část větve není žádný problém, nicméně je to složitější na přesouvání, mazání, vkládání apod.

Napsal Ivorius;175123

Dříve jsem na to používal rekurzivní funkce ale je to dost neohrabané, takže si myslím že ti pomůžu traverzování kolem stromu - jako mě. Vybrat potom nějakou část větve není žádný problém, nicméně je to složitější na přesouvání, mazání, vkládání apod.

To traverzování je opravdu věc pěkná, rád jsem se přiučil. Ale mě šlo o jednodužší věc, než vypsat všechny následovníky, chci vypsat pouze všecny přímé předchůdce. (a hledám nejvhodnější algoritmus - počet dotazů vs rychlost)

Pokud nebudeš nořit moc hluboko, dal bych přednost více jednoduchým dotazům, pro udržení jednoduchého a přehledného kódu. Když by tě začal pálit výkon (ale u tohodle případu bych se toho nebál), můžeš použít cachování - třeba serializovat načtenou strukturu do souboru/apc/memcache a pod.

doporucuju udelat select na vsechny kategorie(vybrat vsechny, coz je 1dotaz) a vysledek zpracovat rekurzivni funkci pres parent_id. v ramci optimalizace se daji rekurzi projet vsechny kategorie, zaznamenat si k nim id potomku(kvuli usnadneni procesu vyskladavani) a cele toto pole kesovat do memcache

O výkon se docela bojím, protože pokud někdo bude hledat například v produktech, u každého je potřeba napsat, pod které kategorie patří (+odkazy na kategorie). Zobrazovat se bude třeba 10 produktů na stránku a každý produkt bude v průměru ve 4. vrstvě, rekurzí bych se dostal třeba na 40 dotazů na stránku, což je pekelně moc. Ta memcache vypadá docela pěkně, ale můžu se na ni spolehnout vždy? (Zatím jsem se díval jenom na pár informací na php.net) Má být spuštěna daemon, a otázka je, jestli alespoň na většině hostinzích je to standard?

Napsal Svaťa;175413

...

memcache urcite standard neni, je to spis tezky nadstandard, kazdopadne si myslim ze i file cache musi byt rychlejsi nez to vzdy prepocitavat

Skoda ze tu nepouzivate compiled linq to sql z .net ;) a ako cache project Velocity :)

Napsal insekticid;175567

memcache urcite standard neni, je to spis tezky nadstandard, kazdopadne si myslim ze i file cache musi byt rychlejsi nez to vzdy prepocitavat

tak tak a pokud to pojede na serveru s dostatkem pameti, aby se ten cachovaci soubor udrzel v systemove cache a script si pro nej nemusel sahat na disk, tak bude vykon srovnatelny s ostatnimi variantami cachovani...