Nested Set Model - riesenie dotazov na databazu

Riesim Nested set model a neviem si rady s dvoma databazovymi dotazmi.
Prvy sa tyka presuvania uzla aj s jeho vsetkymi poduzlami z lubovolnej casti stromu do druhej.
Druhy sa tyka vybratia vsetkych poduzlov konkretneho uzla do urcitej zvolenej hlbky.
Struktura tabulky v databaze ktora riesi nested set model MUSI obsahovat len 4 polozky potrebne pre tuto pracu a to:

ID - primarny kluc
PARENT ID - referencia na primarny kluc tej istej tabulky
LEFT
RIGHT

Ziadne dalsie polozky ako napr. LEVEL a pod. obsahovat nemoze. Ak poznate nieco co riesi nested set model aj s tymito dalsimi doplnujucimi polozkami ani neodpisujte.

Na nete som nenasiel nic co by riesilo tento problem komplexne, poriadne a optimalizovane pre danu strukturu tabulky.
Viete mi priamo napisat ako by mali vyzerat tieto dotazy na databazu alebo poznate stranky kde su tieto veci dobre popisane?
Riesenie by malo byt optimalizovane a dotazov na databazu by malo byt co najmenej ako to ide. Samozrejme transakcie ak su uvadzajte.
V druhom dotaze predpokladam ze sa mozu vyskytovat recursive queries alebo sub queries alebo nieco co ani nepoznam a zjednodusi to dopytovanie - ak taketo moznosti su pre tento problem riesenim tak ich uvedte.

Co sa tyka typu databazy tak to nezalezi - staci ze uvidim dotazy alebo daku teoriu ktora vysvetli ako tieto dotazy spravim. Ale robim v MySQL kedy nahodou.

Dakujem

Tu(a v súvisiacich článkoch) je myslím popísané to čo chceš:
http://php.vrana.cz/traverzovani-kolem- ... kticky.php
Síce tam používa level, ale ak som to dobre pochopil, tak neni nevyhnutný.
A tu sú ešte nejaké ďalšie:
http://interval.cz/clanky/metody-uklada ... atabazich/
http://emer.grafika4u.sk/clanky/php-mys ... eho-dotazu

PS:Prečo NESMIE tabuľka obsahovať level?

V clankoch som nenasiel odpoved na dva mnou spominane dotazy.
LEVEL nesmie byt pretoze je to nadbytocna vec. Jednoducho tam nema co hladat. Cez PARENT ID sa da level urcit tiez.

// pridané po 4 minútach od posledného príspevku

Aby som to trochu lepsie upresnil. Ja potrebujem riesenie na urovni databazy a nie skriptovacie jazyka ako napr. PHP a pod. Teda hladam dotazy na databazu kde sa mozno vyuzivaju aj rekurzie a pod.

Však ti píšem, že ten level je tam ako doplnok a môžeš ho vyhodiť ak sa ti nepáči.
Samozrejme, že pre svoju potrebu to budeš musieť domyslieť sám....

To je všetko odo mňa...

PS:level je číslo v rozsahu tinyint a jeho prínos je určite väčší...

A chces povedat ze tabulka obsahujuca aj pole LEVEL je normalizovana?

Áno!
Bolo by myslím šialené, keby si kôli tinyint stĺpcu musel použiť join...

Rozmýšľam, či to hodím do koša dnes, alebo až zajtra.

Keby si si prečítal prvý z camo-vých článkov, zistil by si, že je tam aj odkaz na presun uzlov. Používa v tabuľkách level, ale určite to zvládneš prerobiť aj bez neho (a prepísať si to čisto do SQL).

A že tabuľka nie je normalizovaná? Ty to máš ako zadanie nejakej úlohy do školy?
Ak áno, tak ďakujem nášmu školstvu, že nám pripravuje nepoužiteľných ľudí.
Že tam "level" nemá čo hľadať? Blbosť. Prečo by som mal komplikovať prácu, keď s tým level-om sú moje skripty efektívnejšie?
Ty sa máš snažiť urobiť efektívnu aplikáciu, nie takú, čo sa slepo drží nejakých odporúčaní. Normalizované tabuľky nie sú vždy ideálne (pre web, resp. pre konkrétne aplikácie).

camo - ten emerov článok je o niečom inom, ten používa iný spôsob ukladania dát.

Dakujem za rady shaggy. Precital som si clanok poriadne a musim priznat ze bolo tam pisane o mojom probleme. Co sa tyka toho levelu tak tiez musim priznat ze asi bude lepsie to tam zahrnut ako nie. A nie je to ziadna uloha zo skoly alebo z roboty len si robim jednu app a chcem ju mat poriadne.
Tak isto dakujem aj tebe camo.

Este raz vdaka.

Shaggy:
Je to iný prístup, ale rozdiel je iba v tom, že je stavaný na jeden dotaz. Jeden dotaz by bol rizikom pri veľkom množstve dát. To tam emer aj spomína. Ale dá sa na ňom robiť aj presun uzlov(aspoň dúfam...) . Ja som ho použil na dynamické menu a dúfam, že tie presuny budú fungovať pre administráciu...

camo - aj pri traverzovaní okolo stromu používaš minimum dotazov (na to je stavaný). Tento spôsob ukladania dát je náročný práve na to ukladanie, ale pri čítaní je rýchly.

quark - myslím, že Jakub Vrána vie o čom píše a ak to tam použil on, nie je dôvod myslieť si, že "level" je zbytočný/nevhodný.

Ja do toho až tak nevidím, ale zaujímalo by ma v čom je vlastne rozdiel medzi tým emerovým prístupom a tým traverzovaním.
Ja som to pochopil tak, že traverzovanie je vždy viac dotazov a hodí sa napr. na fóra, kde je veľký objem dát v DB, čo je riziko prenášať jedným dotazom. A zase na také menu by to boli zbytočné dotazy navyšše.
Mne je zle už keď mám v scripte dva dotazy a mám pocit, že som to prehnal...

Aký je rozdiel medzi menu a napr. stromovou štruktúrou fóra? Žiadny, ani netuším, aký by mal byť problém pri "prenášaní jedným dotazom". Ten objem dát je uplne minimálny (to nie sú megabajty).

Ja napr. používam traverzovanie v mojom CMS na uloženie štruktúry stránok/kategórií a menu zostavujem pomocou jedného selectu. Aj keď si pozrieš tie články od Jakuba Vrány, tak napr. omrvinková navigácia ti "zožerie" max. 2 selecty, čo nie je vôbec veľa.

No dobre díky ja sa tej paranoje z prenášania musím nejako zbaviť...

quark pise ze na databaze nezalezi, tak nech pouzije miesto databazy DATABAZU Oracle a tam ma priamo na urovni sql v selecte clasulu "connect by" ktora to riesi za neho .