Starší komentáře ke článku: Metody ukládání stromových dat v relačních databázích
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 2.3.2005 9:08:59
V pripade "klasickeho pristupu" lze redukovat vyber dat na 1 SQL dotaz v pripade, kdy je znamy pocet urovni, ktere chceme zobrazit od korene (napr navigacni menu do urovne 4 apod.). V tomto pripade napr: SELECT t0.Name, t1.Name, t2.Name, t3.Name FROM test.tree t0 LEFT OUTER JOIN test.tree t1 ON t1.Parent_ID=t0.ID LEFT OUTER JOIN test.tree t2 ON t2.Parent_ID=t1.ID LEFT OUTER JOIN test.tree t3 ON t3.Parent_ID=t2.ID WHERE t0.ID = 1 ORDER BY t0.Name, t1.Name, t2.Name, t3.Name Vysledkem tohoto zjednoduseneho dotazu je: 'Kategorie zboží', 'Procesory', 'AMD', '' 'Kategorie zboží', 'Procesory', 'Intel', 'Celeron' 'Kategorie zboží', 'Procesory', 'Intel', 'Pentium IV' coz lze pro dany fixni pocet urovni neprilis slozitym algoritmem prevest do zobrazeni v podobe stromu.
Datum vložení: 2.3.2005 11:17:19
Ovšem za cenu znásobení objemu přenesených dat. Což může být v určitých situacích kritickým faktorem
Datum vložení: 2.3.2005 13:07:06
Predpokladam, ze mate na mysli prenos dat mezi aplikaci a DB, tj. vlastni vysledek dotazu - nic jineho mi nedava smysl. Nedalo mi to a navrhl jsem si hypoteticky priklad, kdy jsou definovany 4 urovne stromu, kazde NAME vetve ma delku 10 znaku, tj. vysledny vykresleny strom ma 4^4=256 "radku". Dalsi pole, jako ID apod., jsou v prikladu ignorovana. Pokud jsem to vypocital spravne :) tak "klasicky pristup" obnasi 85 SQL dotazu, kazdy vraci 40 (4 podvetve*10) znaku, tj. preneseny objem dat je 3400 znaku. K tomu je potreba pripocitat 85*Delku("SELECT Name FROM TREE WHERE ID = x") na ceste z aplikace do DB, tj. 2890 znaku. Celkem tedy "klasicky pristup" obnasi 6290 znaku. Varianta pro fixni 4 urovne obnasi 1 dotaz (34 znaku "SELECT...") a 256 radku po 40ti znacich, celkem 10274 znaku. Kdyz porovnam, tak se jedna o mene nez dvojnasobek prenesenych dat (navic mezi db a aplikaci, v praxi to nebyva casto uzke hrdlo) s vyznamnym ulehcenim SQL databazi. Je take treba vzit v uvahu, ze vysledek onoho jednoho objemnejsiho dotazu je velice snadno uchovavatelny v "cache"(napr. pomoci objektu Application v ASP) pokud se struktura stromu nemeni casto (napr. menu kategorii produktu v nejakem eshopu). Priklad berte s rezervou, nicmene "k veci" ;-)
Datum vložení: 2.3.2005 13:38:57
V duchu článku, kde je u každého přístupu uvedeno pozitivum i negativum, jsem to druhé doplnil. Měl jsem spíš na mysli situace, když je v tabulce velký binární objekt, nebo když se používá dedikovaný databázový stroj, nebo dokonce obojí. (v tom výpočtu tuším drobnou chybičku, řádků by mělo být 341 = 4^4 + 4^3 + 4^2 + 4^1 + 4^0).
Datum vložení: 8.3.2006 19:31:57
muzes k tomu SQL dotazu dat nejake vysvetlivky, nejsem z toho dvakrat moudrej :( a zrovna tohle ted potrebuju....
Datum vložení: 27.8.2007 22:11:12
Sice je tento komentar i clanek pekne stary, ale stejne mi to neda a musim na ty hlouposti reagovat. Inteligentni programator si jiz davno napsal tridu ItemList, *jedinym* dotazem ji naplni vsemi daty (tedy id, name, value, p_id) a ona pote vraci o co pozadame. Vyhoda je, ze ten jeden dotaz trva vzdy kratsi dobu, nez vase desitky zbytecnych dotazu ci spinave joiny. Predevsim v pripade kdy SQL server pobezi na jinem fyzickem stroji, nez je PHP/Apache server je rozdil nejmarkatnejsi. SQL DB dobre cachuje, persistentni spojeni mame, nechapu proc dementne komplikovat tak jednoduchou cinnost. Jinak povazujte za samozrejmost, ze presouvani zaznamu ci jejich upravu obslouzi ItemList a az ve svem destruktoru ulozi zmeny (pokud nejake nastaly)
Datum vložení: 16.9.2007 12:02:12
nedalo mi to a musim reagovat na Vas sebejisty prispevek. Inteligentni programator si uz urcite napsal Vasi tridu, pokud nema k dispozici poradnou komponentu, ktera tyhle veci resi za nej v pozadi. A HLAVNE pokud si je 100% jisty, ze mu ta Vase GENIALNI trida v budoucnu nenacte 100mega do te sve cache. Pokud si tim 100% jisty neni, jedna se pouze o "Ynteligentniho" programatora s velkym "Y".
Datum vložení: 2.3.2005 10:01:43
Práve niečo podobné riešim a pred dvoma dňami som sa odhodlal použiť poslednú metódu. Inak si myslím, že podobné články len prispievajú k informovanosti programátorov ktorým chýbajú (matfyzácke) základy (ako som napríklad ja :-D) k informovanosti o tom čo všetko sa dá z použitím dobrého algoritmu dosiahnuť. Len tak ďalej a viac!
Datum vložení: 2.3.2005 10:53:19
posledni metodu uz sem nekolikrat videl ovsem je to stale stejne v prikladu je hezky uvadena leva a prava hrana, a kazdy prvek ma prave 2 potomky co takhle uvest co delat v pripade ze uz treba korenovej element nema 2 ale treba 5 deti, jak se potom deli hrany, nejak mi to hlava nebere
Datum vložení: 2.3.2005 11:21:20
Na počtu potomků přeci vůbec nezáleži, můžete klidně dokreslit další větev a zvýšit číslo na pravé hraně rodiče. To je jen nešťastně zvolený obrázek, že vidíte u každého prvku právě dva potomky. Ale kdybyste s tím nepřišel, vůbec bych si toho nevšiml :-)
Datum vložení: 2.3.2005 11:49:10
No nevim nevim, podle me tam je par zasadnich nedostatku hlavne co se tyce aktualizace udaju na hranach Co takhle predvest nejaky vhodnejsi priklad na kterem je videt ze tohle bude fungovat kdyz prvky budou mit ruzne pocty deti treba od 1 do 5 Hlavne jak nasledne funguje vlozeni noveho ditete do stromu a aktualizace udaju na hranach aby se zachovala integrita
Datum vložení: 2.3.2005 12:08:52
Vážně si zkuste vzít tužku a papír a vyzkoušet si to. Ten uvedený algoritmus evidentně bude fungovat na libovolný počet dětí včetně nemanželských. Nesuďte stále podle zjednodušeného obrázku.
Datum vložení: 2.3.2005 12:33:20
Ano dokazu si predstavit slozitejsi diagram kde vsechny hodnoty na hranach budou krasne sedet a vsechno a vsichni budou cool ale to neni ten problem Jak je zajistena konzistence struktury pokud se rozhodnu doprostred struktury vlozit nekolik novych zaznamu pripadne nekde jine smazu celou jednu vetev s X dalsimi vnorenymi elementy?
Datum vložení: 2.3.2005 17:48:44
přečti si radši pořádně celý článek.. u této metody se záznamy přidávají/mažou PO JEDNOM a PO KAŹDÉM smazání/přidání se struktura přepočítá..
Datum vložení: 2.3.2005 20:47:27
ty lamo, mazani po jednom kdyz je potreba promazat, celou vetev kde je treba par tisic uzlu??? a co presouvani kdyz potrebujes jeden uzel presunout pod jineho rodice??? Lama se pozna pozna podle toho ze neuvazuje (viz. ty), jak vidim me hlodani z nekde je neco spatne na tehle moznosti ukladani dat se ukazuje jako spravne :-)
Datum vložení: 4.3.2005 9:31:39
Tvoje hlodani ukazalo lecos, ale ne nevhodnost tohodle algoritmu :) 1) Přidání uzlu: Vybereš si místo kam ho chceš vložit a z toho dostaneš levý a pravý index, který tvuj nový uzel bude mít. 1a) vkládáš list: Všechny indexy, levé i pravé, které jsou větší nebo rovny indexům nového uzlu zvětšíš o 2. Vložíš nový uzel a máš hotovo. 1b) vkládáš vnitřní uzel: potomkům nového uzlu zvětšuješ indexy o 1, ostatním stejně jako v 1a. 2) odebrání uzlu: předpokládám že znáš levý(dl) a pravý(dr) index odebíraného uzlu (kořenu odebíraného podstromu). DELETE FROM tree WHERE l>=dl AND r<=dr UPDATE tree SET l=l-(dr-dl+1) WHERE l>=dl UPDATE tree SET r=r-(dr-dl+1) WHERE r>=dr Všechny 3 dotazy můžeš poslat DB serveru najednou. 3) přesun uzlu a podobné skopičiny: co si budeme povídat, neni to nic jednoduchého. 3a) Za prvé je potřeba si uvědomit že to neni příliš častá operace. Těžko si představit, že budu chtít v e-shopu přesunout kategorii LCD monitorů pod procesory AMD :) Složitost této operace je vykoupena jednoduchostí dalších operací. 3b) Podle mě je nejefektivnější metoda vytáhnout celý strom do paměti, přeindexovat, a změny uložit.
Datum vložení: 2.3.2005 12:17:20
výborně, petře! přehledný a srozumitelný článek, který hlavně začátečníky ale i pokročilejší programátory seznámí se základními možnostmi.
Datum vložení: 2.3.2005 12:49:46
Nečítal som to celé, ale silne mi to štruktúrou aj obsahom pripomína starší článok na Sitepointe http://www.sitepoint.com/article/hierarchical-data-database
Datum vložení: 2.3.2005 13:25:14
Celé mi to připadá jako nesmysl. Myslím, že ne-li ve všech, tak ve většině případů je nejefektivnější celý strom kategorií po celou dobu [b]udržovat v paměti[/b] a v databázi je u položky uložen pouze přislušný klíč. Ještě jsem se nesetkal s tak velkým stromem, který by mohl zabírat řekněme více jak 10 MB, což je dnes nic moc. Nevím, zda to PHP umí, ale Java a NET ano.
Datum vložení: 2.3.2005 13:32:29
Mel jsem pocit, ze clanek je o tom jak namapovat stromovou strukturu do relacni databaze a ne o tom, co je vhodnejsi...
Datum vložení: 2.3.2005 13:49:07
"Já vaši <|> taky neviděl a přesto věřím, že ji máte." Co na to říct? Jako programátora bych Vás nezaměstnal :-) (nic ve zlém)
Datum vložení: 2.3.2005 14:28:17
To jsem bohužel nějak nepochopil... (nic ve zlém).
Datum vložení: 2.3.2005 19:46:07
Tak pomaleji. Tento článek je z hlediska přínosnosti a vůbec zpracování špičkový. Nevidím tu žádné hýření superlativy, není tu chváleno žádné polovičaté řešení. Jen čtivě podaná fakta, každá zmíněná výhoda řešení je doplněna i jeho nevýhodou. Z tohoto hlediska je už komentář začínající slovy "Celé mi to připadá jako nesmysl" podezřelý. Ale proč ne, pokud jej podpoříte argumentem hodným tohoto článku. Ovšem věta "Ještě jsem se nesetkal s tak velkým stromem, který by mohl zabírat řekněme více jak 10 MB" tomu jen nasazuje korunu. To už kdysi tvrdil někdo jiný http://www.google.com/search?q=640+K+should+be+enough+for+everyone
Datum vložení: 3.3.2005 0:20:46
Zase zde nečtu žádný argument, ale pouze slušně napsané invektivy. Je to ovšem alespoň srozumitelnější než předchozí příspěvek. Mě se také článek zdá napsaný dobře a ukazuje některé použitelné algoritmy. Přesto mi navrhovaná řešení připadají ve většině případů nevhodná. Abych také jenom dutě nementoroval, tak se pokusím uvést nějaké zkušenosti. V nedávné minulosti jsem měl možnost pracovat na projektu, který pořeboval zobrazovat některá data zařazená do katagorií ve stromu. Sice nebyl psán v PHP,ale to snad není podstatné. Poměrně dlouho jsme se tím zabývali a řešení přes databázi je špatné. V určitých situacích jsem museli pro zobrazení jedné stránky položit i několik desítek Selectu nebo použít outer join, což je totéž a někdy kupodivu i pomalejší. Ideální je podle mého názoru a zkušeností, jak jsem již psal, načít struturu jedenkrát za chod aplikace do paměti a v databázi mít pouze vlastní data. Druhou možností je alespoň načíst při pro jeden request celou strukturu tj. jeden select a potom to zpracovat v paměti. Další možností je data načít do nějaké cache, která se jednou za čas aktualizuje. Všechny v článku uvedené postupy nejsou vhodné pro zatížený systém, ale pouze pro malé obchůdky a služby.
Datum vložení: 3.3.2005 11:44:25
No asi jste to nepromysleli poradne. Podivej se na rastrovou variantu - tzn. ukladas informace o Xove a Yove souradnici kazdeho uzlu. Potom libovolnou cast podstromu nactes prave jednim SQL dotazem. Nejrychlejsi! Zadne LEFT JOINY atd. Je to sice narocnejsi pri ukladani nebo presouvani podstromu, ale zas ne tolik. Naprogramujes jednou obecne do knihovny, a pouzivas v ruznych pripadech. Nacitani do pameti me prijde silene, zvlast pri velkych strukturach (tisice uzlu). Zrejme jste zvolili metodu odkazu na otce, ktera prave trpi mnoha dotazy pri nacitani jen casti podstromu. Rastr je OK!
Datum vložení: 2.3.2005 15:01:54
Příklad stromu, který by byl nesmysl udrožovat v paměti je třeba tato diskuze - protože co jiného je diskuze uspořádaná podle vláken než stromová struktura? Právě nedávno jsem pro sebe, právě pro účely diskuze pod článkem, "vynalezl" způsob uvedený v článku jako "rozšíření ploché tabulky". Až budu mít čas tak si promyslím "Traverzování kolem stromu" jestli nebude pro moje účely vhodnější, ale asi nebude.
Datum vložení: 25.3.2005 12:16:55
Clanek se zabyva databazemi. Jak chcete v pripade drzeni v pameti resit viceuzivatelsky pristup?
Datum vložení: 2.3.2005 13:34:27
Zajimalo by me, proc myslite, ze pouziti zasobniku bude mene narocne, nez rekurzivni funkce. Vzhledem k principu rekurzivniho volani mi to prijde uplne stejne.
Datum vložení: 4.3.2005 15:11:33
Volání rekurzivní fce. je v podstatě také ukládání do zásobníku (v tomto případě ale systémového). A když to s rekurzí přeženeš, tak hádej co?... STACK OVERFLOW! Ale vždycky jsem se učil, že rekurzivní fce. jsou paměťově náročnější než ukládání do zásobníku přímo v programu.
Datum vložení: 4.3.2005 17:43:37
hmm. zalezi na spravovani pameti. btw, "vzdycky jsem se ucil" je argument jak vino :)
Datum vložení: 22.3.2005 21:06:57
pouziti rekurze je pomalejsi, protoze se na zasobnik ukladaji argumenty funkce (jako lokalni promnene)
Datum vložení: 18.11.2007 7:56:41
Použití rekurze je pomalejší, protože používáš zastaralý software. Moderní implementace programovacích jazyků optimalizují minimálně tail cally, pokud rovnou neprovádějí i inlining listových funkcí.
Datum vložení: 26.4.2008 11:40:18
Inlining rekurzivních funkcí s neznámou úrovní zanoření se provádí poměrně těžko. Navíc článek je v PHP, které je interpretovaný jazyk a tam se nepoužívá nějaký šílený optimalizující překadač. K původnímu dotazu, proč je zásobník rychlejší: V paměti se uchovávají víceméně jen data. Při rekurzi se v systémovém zásobníku musí uchovávat parametry každého volání funkce, návratová adresa volání a vlastní vrácená data se také musí někam nacpat.
Datum vložení: 2.3.2005 15:58:51
Chválím autora za povedený článek. Možná jsem něco přehlédl, ale nedala by se aktualizace stromu při vložení listu ve třetím případě řešit jednoduchými dvěma dotazy? "UPDATE tree SET lft = lft + 2 WHERE lft >= $lft" "UPDATE tree SET rgt = rgt + 2 WHERE rgt >= $lft" ($lft je lft vloženého listu) Jakub Vrána, http://php.vrana.cz/
Datum vložení: 2.3.2005 16:09:58
Aha, jak jsem se dozvěděl v článku http://www.sitepoint.com/article/hierarchical-data-database, tak to možné opravdu je. Nechci autora podezírat z plagiátorství (když už jsem mu text pochválil), ale články jsou si opravdu nápadně podobné - strukturou, předvedenými funkcemi a třeba i použitými identifikátory tabulek a sloupců (lft a rgt přeci jen není úplně typické). Jakub Vrána, http://php.vrana.cz/
Datum vložení: 2.3.2005 16:34:24
ovsem opet je zde otazka pouze 2 "deti", stale ve me hloda jakysi vnitrni hlas ze "nekde je neco spatne", jak spravne udrzovat konzistenci pokud mam vic nez 2 deti a nekde doprostred stromu pridam par zaznamu a nekde jinde zase uberu celou vetev vc. vnorenych?
Datum vložení: 2.3.2005 18:05:19
Pokud nerozumite tomu poslednimu prikladu tak doporucuji google a hledat neco jako [i]Celko Nested Sets[/i]. Pokud se dobre pamatuji je na www.phpclasses.org hotova trida pro PHP i s updaty a vsim. Jinak je pravda, ze tato metoda se hodi spise na velmi malo updatovane stromy, protoze updaty sou narocnejsi.
Datum vložení: 2.3.2005 17:48:55
V tomto pripade jsou lft a rgt naprosto bezne - pouziva se misto left a right coz jsou v SQL klicova slova takze je neni mozno pouzit.
Datum vložení: 2.3.2005 19:35:14
je třeba zapsat <left< a <right< - shoda identifikátoru a klíčového slova je spíš argument začít konečně používat zpětné uvozovky. Co když v další verzi MySQL se objeví naprosto nové klíčové slovo RGT?
Datum vložení: 2.3.2005 16:12:43
Pane Vráno, přestaňte se zbytečnými odkazy na své stránky, nebo budu nucen vaše příspěvky mazat, v souladu s politikou diskuse pod články (i když jsou fakticky přínosné ;-(
Datum vložení: 3.3.2005 9:52:37
jako ctenari mi prijde uzitecne, kdyz si muzu udelat o diskutujicim obrazek na zaklade jeho stranky
Datum vložení: 3.3.2005 10:31:02
No, a třeba mi zase ne... Neumím si představit že by to dělali všichni. Jako by na inetu nebylo dost reklamy, ještě tady v diskuzích... :-( Nepřijde mi správné hodnotit příspěvek podle webu autora. To je ale jen můj názor.
Datum vložení: 3.3.2005 12:11:27
Pokud se na jeho (či jýchkoli jiných) stránkách nachází něco přínosného diskusi, pak je to vpořádku. V opačném případě jde jen o informační šum. Web autora příspěvku je irelevantní, pokud se danou problematikou nijak nezabývá...
Datum vložení: 4.3.2005 9:38:30
Když to doženeme do absurdna, neni podpis pod příspěvek nepřípustná reklama na moji osobu? Příspěvky pana Vrány jsou naprosto k věci a odkaz na stránky součást jeho podpisu. Mě to přijde v pořádku. Ale koneckonců, je to váš server :) Ondra Vošta
Datum vložení: 4.3.2005 11:22:59
Od toho je tu políčko "Jméno", ne? Podpis pod příspěvkem na mě spíš působí, jako by šlo o citát :-) p.s. fórum zaměňuje znaky #60 za < - proč to?
Datum vložení: 4.3.2005 15:09:17
Jde o druhotný efekt bezpečnostního filtru, který nejprve potenciálně nebezpečné znaky převádí na entity, nad nimi provádí "čištění" a teprve poté odesílá text na výstup (k zobrazení). Filtr zároveň reformátuje starší příspěvky, které se zadávaly několika různými způsoby, proto je takto "tvrdý". Pokud chcete napsat takovou entitu tak, aby se skutečně jako entita zobrazila, musíte ji zapsat jako kombinaci entity pro ampersand a zbytek znaků, tvořících původní entitu. Doporučuji otestovat v náhledu, není tak těžké to odhadnout... Píši < nebo <? ;-)
Datum vložení: 4.3.2005 15:16:07
Tedy, druhotný efekt je to jen v tomto případě. Systém je utvořen tak, aby umožňoval zadávat speciální znaky entitami, proto entita se zobrazí jako speciální znak a ne jako řetězcová reprezentace entity. Hm, když to po sobě čtu, řekl bych, že dokáži mnohem snáze naprogramovat systém, aby dělal to, co chci, než toto "chtění" vysvětlit ostatním. Ale to nevadí, hlavně že to funguje - a otestovat se to dá v náhledu ;-)
Datum vložení: 4.3.2005 21:14:42
Nojo, ale Vám se zapsat ten znak taky nepodařilo (nevyjádřil jsem se přesně - myslel jsem hex 60) Tuším, kde je problém - v tom převádění na entity. Znak s kódem hex(60) se chybně změní na entitu < namísto korektního ` A pak z toho v druhém kole vznikne levá ostrá závorka.
Datum vložení: 5.3.2005 2:15:15
Vždyť říkám, že v tomto případě jde o vedlejší efekt bezpečnostního filtru ;-)
Datum vložení: 5.3.2005 10:37:33
Víte, to je ale zvláštní, když napíšu `, tak normálně dostanu horní jednoduchou zpětnou uvozovoku? Tedy "`" - to jste chtěl napsat, ne? Nezapomněl jste v původním příspěvku na "x", jako označení hexadecimální soustavy? ;-(
Datum vložení: 5.3.2005 16:13:43
Nepoužil jsem vůbec entity, prostě jsem napsal horní jednoduchou zpětnou uvozovku, zkuste si to.
Datum vložení: 5.3.2005 16:20:03
Aha, tak teď už to chápu, opravdu to dělá ten bezpečnostní filtr, protože hexa 60 je decimálně levá ostrá závorka. Takže prostě příště napište entitu (decimálně je to 96) a dostanete uvozovky ;-)
Datum vložení: 2.3.2005 16:59:43
Ćlánek je to celkem zajímavý, ale to přepisování rekurze na iterace je celkem amatérismus. V takové aplikaci je to zbytečná práce, žádné zrychlení to nepřinese.
Datum vložení: 6.3.2005 18:29:34
Nemohu plně souhlasit s autorem a to hned z několika důvodů. Přepis rekurze na iteraci ponechává programátorovi plnou kontrolu nad tím, co přesně se bude do zásobníku ukládat. Standardní rekurzivní funkčnost ukládá do zásobníku veškerá data nutná pro obnovení při návratu z rekurzivní funkce. Toto může být občas problém jedná-li se o velice krátké rekurzivní volání, kde čas rekurzivního zavolání byl srovnatelný s délkou trvání reukrzívní funkčnosti. Dalším problémem mohou být paměťové nároky. Souhlasím však s autorem, že přepis rekurze na iteraci není příliš obvyklá věc.
Datum vložení: 2.3.2005 20:23:34
/** * Transformuje zoznam uzlov stromu/lesa na strom/les * * @param array $nodes Zoznam uzlov stromu/lesa, indexovany podla ID uzla * @return array Zoznam korenov stromov * */ function & listToForest(& $nodes) { $roots = array(); foreach ($nodes as $nodeID => $node) { $parentID = $node['parent_id']; if ($parentID === null) // nema parenta, je to koren $roots[] =& $nodes[$nodeID]; else { // ma parenta, prevesime ho do jeho children kolekcie $parentNode =& $nodes[$parentID]; if (!array_key_exists('children', $parentNode)) // parent este nema children kolekciu $parentNode['children'] = array(); $parentNode['children'][] =& $nodes[$nodeID]; } } return $roots; } // pr. $nodes = array(); $node = array('id' => 0, 'parent_id' => null); $nodes[$node['id']] = $node; $node = array('id' => 1, 'parent_id' => 0); $nodes[$node['id']] = $node; $node = array('id' => 2, 'parent_id' => 0); $nodes[$node['id']] = $node; $node = array('id' => 3, 'parent_id' => 1); $nodes[$node['id']] = $node; $node = array('id' => 4, 'parent_id' => 1); $nodes[$node['id']] = $node; $roots = listToForest($nodes);
Datum vložení: 2.3.2005 22:56:19
1) konstrukce: foreach($nodes as $nodeID => $node) zpusobi ze $nodeID nebude obsahovat ID nodu ale jeho index v predavanem listu, coz znamena ze to nebude pouzitelne na data z databaze kde jsou nektere nody smazanae a tudiz ciselna rada neni spojita 2) cela ta smycka je dobre pouzitelna pouze v pripade ze predavany list obsahuje vsechny nody dokonale serazene v poradi od nejvyssich rodicu na zacatku az po posledni bezdetne prvky na konci, pokud by v seznamu bylo dite drive nez jeho rodic je tu jisty problem, v pripade PHP to sice zafunguje diky volnosti pri odkazovani prvku pole ale osobne to povazuju za prasarnu v zajmu lenosti 3) vysledny -strom- bude mit jednu zasadni chybu a sice nebude to strom ale jen jinak definovany list vsech elementu (na prvni urovni seznamu budou vsechny elementy namisto tech ktere jedine maji za sveho rodice koren stromu)
Datum vložení: 3.3.2005 9:36:22
1) verim ze z komentara k rutine aj z prikladu je jasne ze vstupom je asociativne pole (hashmapa) oindexovane IDckami nodov, nie linearne pole 2) nie je to pravda, ak je tam child skor, nic sa nedeje - prevesi sa k parentovi ktory je v mape neskor. Opet si treba uvedomit, ze vstupom je hashmapa referencii na nody podla ID, cez ktoru len iterujem, nemodifikujem ju, takze je to ok v akomkolvek prostredi. Modifikacia stavu objektu na ktory mam referenciu v kolekcii pri iterovani cez nu je v poriadku. 3) nie, vystupom je nove pole, do ktoreho su zaradovane len referencie na uzly bez parenta - korene (je to overene praxou)
Datum vložení: 2.3.2005 20:50:24
Pre rozsirenie moznosti dotazovat stromove struktury z RDBMS inak ako len nacitat cely strom (dost podstatne pre naozaj rozsiahle stromy/lesy) sa hodi udrziavat si v databaze spolu so samotnymi uzlami aj uzaver relacie parent<->child (obsahujuci jeden zaznam pre kazdu kombinaciu predka a potomka v strome). Algoritmy pre rebuild/udrziavanie uzaveru sa mozu nachadzat bud v BL aplikacie, alebo v stored procedurach navesenych na triggery nad tabulkou tree_node. /* Uzly stromu s referenciou na parenta */ create table tree_node ( id integer, parent_id integer, ... node data ... ); /* Uzaver relacie parent<->child */ create table tree_closure ( ancestor_id integer, descendant_id integer, distance integer ); -- Uzly podstromu od @root_id select tree_node.* from tree_node, tree_closure where tree_node.id = tree_closure.descendant_id and tree_closure.ancestor_id = @root_id -- Cesta od @leaf_id po root select tree_node.* from tree_node, tree_closure where tree_node.id = tree_closure.ancestor_id and tree_closure.descendant_id = @leaf_id order by tree_closure.distance
Datum vložení: 3.3.2005 8:26:00
Jen maly dodatek k te posledni metode. Tato metoda ziskava dalsi body, pokud se pouzije nejaka sofistikovanejsi databaze nez je MySQL. Je dobre pouzit stored procedures a napsat si obecne funkce pro praci se stromem. S tim pak souvisi rozdeleni do vice tabulek. V jedne stromova struktura (aby s ni mohli operovat obecne funkce) a ve druhe vlastni data. Celkem pekny priklad je zde: http://affy.blogspot.com/ntm/ Priklady jsou pro SQL server, ale neni problem prepsat si je pro jiny DB system. Sam tuto metodu uspesne pouzivam v PostgreSQL. Ted si ale nejsem zcela jisty, jestli ve vyse uvedenem clanku nebyla nejaka chyba v implementaci nejake funkce, kterou jsem musel opravovat. Pri pochopeni teorie to ovsem neni problem.
Datum vložení: 5.3.2005 23:58:25
Pri pohledu na tabulku u "klasickeho pristupu" jsem si vzpomnel na moji zkousku z Databazovych systemu, ze ktery sem vylit kvuli tomu, ze muj relacni model nebyl relacni :) Jde o to, ze tady ma korenovy uzel stromu PARENT_ID = 0. Ja jsem mel ve svem modelu (online chat) v tabulce zprav atribut ID_ADRESAT ktery mel nulovou hodnotu pro zpravy urcene vsem lidem a nenulovou pri "septani". Cele to fungovalo v pohode (i v realite) a splnovalo to me pozadavky, ale zkousejici me stejne vyhodil, protoze to prece odporuje podminkam relacnosti :o)...no to bylo asi trochu off-topic ze?
Datum vložení: 7.3.2005 15:49:35
Nepřijde mi to off-topic, správně by tam opravdu mělo být NULL a ne 0.
Datum vložení: 8.3.2005 15:10:06
Ted to neberte jako urazku. Null by tam mel byt urcite nebo muze byt 0 a pak na koreni udelat uzaveru tedy otec sama sebe. Problem s 0 je ten, ze stavi urcity zaznam do polohy zavisle na pozici, cimz porusuje pravidlo relacniho systemu. Pokud by jste to bral strictne jako na zk, pak neexistenci zaznamu s ID=0 porusujete referencni integritu (delate relaci cizim klicem na tabulku samu) ale pokud zajistite existenci zaznamu s ID=0 pak tento zaznam se stava necim specialnim, necim vice nez zbytek zaznamu a tim porusujete pravidlo relacniho systemu. 0 je hodnota, i kdyz v praxi ma vyjmecne postaveni, zde ma stejne jako napr. 10 -1 100. NULL neni hodnota (proto nejde =NULL ale is NULL) a ma prave jenom ten specialni vyznam niceho tak jak cislice 0 v zivote.
Datum vložení: 6.3.2005 14:44:29
Proc se vyskytla potreba psat o ulozeni stromu? Viz clanek na Rootu.
Datum vložení: 6.3.2005 16:05:28
Tento clanek vznikl a vysel drive nez na rootu, takze vase pripominka patri spise na root. Nehlede na to ze tema clanku bylo domluveno uz cca pred pul rokem :-)
Datum vložení: 11.3.2005 19:48:12
Tam jsem taky psal http://www.root.cz/clanky/stromy/
Datum vložení: 7.3.2005 6:57:12
Je fakt, že ORACLE asi jen tak někdo nebude provozovat doma, ale už někdy ve verzi 7 se na něm dal strom procházet klauzulí SELECT ... CONNECT BY PRIOR ... START WITH.
Datum vložení: 17.3.2005 11:06:00
zajimalo by me jestli pri pouziti prvni metody; tedy rekurze by bylo mozne vyuzït cachovani a ti padem zrychlit vypis dat, protoze na webu by se pri kazdem http pozadavku tezko menil strom, ale nevim jak cachovani provadet diky
Datum vložení: 17.3.2005 11:50:35
Staci si vysledny strom pri prvnim pozadavku vygenerovat do textoveho souboru a pak ho jenom includovat. Pripadne v serializovane podobe ukladat strom do databaze nebo zase na disk. Dale musite zajistit, to aby pri jakekoliv editaci polozky ve stromu se strom vygeneroval znovu.
Datum vložení: 17.3.2005 15:07:27
no prave;) musim zajistit ze kdyz se zmeni strom v db aby se to natahlo znova ale diky, potrebuju to pouzit, mam web s padesati odkazy a tolik selectu je asi osklive takze si to vytahnu a vlozim do naky sablony kterou includuju; ok; to mi pomuze; jen to zajisteni opetovneho natazeni slo by to i nakou expiraci? nebo jak kontrolovat zmenu v tabulce (pribyl odkaz, nebo zmena odkazu)
Datum vložení: 17.3.2005 20:20:19
"slo by to i nakou expiraci?" Asi taky, ale misto HTTP hlavicky Expires nebo novejsi Cache-Control: max-age bych pouzil neco jineho - ETag je Vas kamarad :-) Leo
Datum vložení: 17.3.2005 16:57:12
Myslím, že znám lepší řešení ukládání stromu do databáze. Resp. asi jak na co, ale pro většinu aplikací ano. Uvedu příklad pro diskuzní fórum. Bude zde jen jedna tabulka. V ní budou standardní řádky autor, text atd. a také [b]řádek "vlakno"[/b] typu VARCHAR. A fungovalo by to následovně: Příspěvky, které by byly na vrcholu stromu, by měly atribut [i]vlakno[/i] [b]"A", "B", "C"[/b] atd., postupně za sebou. Příspěvky, které by byly odpovědí příspěvkům na vrcholu stromu, by měly [i]vlakno[/i] [b]"AA", "AB"[/b] (pro odpověď na [b]"A"[/b]), [b]"BA", "BB", "BC"[/b] (pro odpověď na [b]"B"[/b]) atd. Příspěvky třetího řádu by měly [i]vlakno[/i] [b]"AAA", "AAB", "AAC"[/b] atd. Z každého příspěvku by tedy šlo vysledovat, kde přesně se ve stromu nachází. A jak se hledá: stačí [b]1 požadavek[/b] pro vypsání celého stromu: [i]SELECT * FROM forum ORDER BY vlakno[/i] Tím by se i strom seřadil přesně podle vláken příspěvků. Chtěli-li bychom vypsat pouze příspěvky z vlákna "B", bylo by to [i]SELECT * FROM forum [b]WHERE vlakno LIKE "B%"[/b] ORDER BY vlakno[/i] a je to. A zapsání: stačí pouze zjistit [b]nejvyšší použité číslo podvlákna[/b] a vytvořit o 1 větší. Tedy jsou-li v databázi záznamy "A", "B", "BA", "C" a chceme další odpověď pro "B", bude to [b]"BB"[/b]. Toto řešení je velice snadné na implementaci, šetrné k databázi, de facto stačí jeden požadavek na databázi pro výpis celého stromu. Na druhou stranu je omezený počet příspěvků v jedné hloubce stromu. To se však dá snadno obejít tím, že 1 stupeň vlákna nebude pouze 1 znak, ale 2 nebo 3, možné je rozšíření nejen na "A-Z", ale i "O-9" či "a-z". Tohle řešení mě "jen tak" napadlo, a divím se, že se tu o něm nepíše...
Datum vložení: 25.3.2005 12:13:09
Vami navrhovane resemi me prijde slozite a nesikovne. Prvni problem vidim v pripade castejsiho mazani ci vkladani zaznamu, kdy by jste musel 1) hledat diry v sekvencich, a ty vyuzivat 2) pouzit posledni sekvenci, potom Vam ale pomerne brzo muze dojit 'abeceda'. Podobne v pripade ze budete potrebovat znat dopredu hodnotu zaznamu se muzete dostat k diram. Kontrola dat na udrzeni integrity by nebyla moc jednoducha a stringove dotazy jsou pomalejsi. Samozrejme nic z toho neni neresitelne, ale za cenu slozitych kontrol, navic textove pole Vam zabere vice mista. K samotnemu clanku - rozdil popsanych metod me prijde pouze v pridani redundantnich sloupcu, ktere se daji nahradit pocitanym sloupcem. Proc nepouzit CONNECT BY PRIOR? Hierarchicke dotazy vse velmi zjednodusi.
Datum vložení: 13.4.2005 14:22:40
Složité? Přijde mi to rozhodně přirozenější než veškeré jiné uvedené metody. Vkládání a mazání záznamů: Díry v sekvencích hledat nemusím, a ani nebudu. Poslední příspěvek budu vkládat vždy za poslední záznam, vložit ho do té díry by byl nesmysl. Toho, že by došla abeceda, se nebojím. Využiju-li 3 znaky posloupnosti 0-9 a A-Z, mám asi 37.000 možných odpovědí. Kromě toho si ty záznamy můžu jednou za čas přetřídit. Kontrola dat je jednoduchá - musí existovat to vklákno, do kterého vkládám, a všechny nadřazené. To je jeden požadavek do databáze. A pak jen k tomuto vláknu přidám "příponu" - poslední odpovědi na tento příspěvek + 1. Že stringové dotazy jsou pomalejší, to je pravda, zabere i více místa. Ale za cenu mnohem jednoduššího zpracování a značné úspory databázového času díky méně požadavkům.
Datum vložení: 24.8.2006 14:47:17
(rok sem, rok tam:-)) Kolega spis mel na mysli, ze dojde abeceda treba u nejakeho prispevku, na ktery se sejde vic nez (treba) 62 (26+26+10) odpovedi. Situace neni nerealna... Resenim je jen pridavat dalsi znaky do 'setu'. S touto metodou bychom se mohli dopracovat k identifikatorum napr. 20z (v prvni urovni jde o treti prispevek, ve druhe o prvni a ve treti o sedesaty druhy; pro sedesaty treti uz zde misto neni -- pouzil jsem set znaku [0-9A-Za-z] s tim, jak jdou v ASCII za sebou... Samozrejme neni problem pouzit znaky od ascii 32 (mezera) az po ascii 255, ale i tak je tam ten limit na pocet "potomku" na 256-32
Datum vložení: 30.7.2008 2:17:13
Tohle řešení je jednodušší než všechna řešení v původním článku. Ad mazání záznamu a díry) po smazání záznamu se dí záznamům v jeho úrovni, které jsou za ním, (a jejich potomkům) zmenšit prvek vlákna o 1 na dané pozici. Je to opět jenom jeden dotaz. Pouze pro mazání většího množství záznamů by bylo lepší je smazat najednou a pak vlákna přepočítat. A to jen na dotčených větvích. U jiných případů by se musel procházet a přepočítávat celý strom, tak mi řekněte, v čem je to "slozite a nesikovne". Dále píšete: "Kontrola dat na udrzeni integrity by nebyla moc jednoducha". Jednak je to blábol, ve kterém dokazujete neznalost pojmů, jednak to není pravda. "stringove dotazy jsou pomalejsi" - výhoda v jednom dotazu na výpis, posílanému SŘBD oproti např. 100 dotazům v některé z výše zmíněných metod (není nereálné) je mnohonásobně větší. "textove pole zabere vic mista" - uvádět tohle jako aspekt ohledně rozhodování, jaký způsob použít, je směšné. Takhle metoda je ve všech ohledech nejlepší tam, kde víte, že při daném zvolení počtu znaků (to je to "A", "AA", "AAA", ...) nepřekročíte maximální počet položek pod sebou (počet reakcí na příspěvek, počet zboží v kategorii) i vedle sebe (počet do sebe navzájem vnořených reakcí, kategorií..). Metody v pův. článku takové omezení sice nemají, ale silně pochybuju, že v praxi bude existovat e-shop, který má v nějakém bodě milion kategorií s maximální délkou zanoření tisíc úrovní.
Datum vložení: 30.7.2008 2:25:32
a pokud by měl, tak většině řešení v pův. článku při načítání položek do objektů dojde paměť :-)
Datum vložení: 30.4.2005 11:21:45
vskutku originální nápad... http://www.builder.cz/art/php/disccuss_sql.html ale stejne mi to nepripada moc vhodne
Datum vložení: 22.3.2005 9:41:51
Zase po dlouhe dobe pekny a uzitecny clanek. Priznam se ze posledni variantu jsem neznal a tak jsem nove nabytymi znalostmi nadsen. Dalsi zachvat veseli mne ale postihl pri cteni diskuse k clanku. Nemam ani tak namysli omezenost nekterych jedincu ale spise bravurni dilalog o interperetaci znakovych entit. Dlouho jsem se tak nepobavil, gratuluji. :-)
Datum vložení: 22.3.2005 20:33:18
Promiňte, ale vám se ještě nikdy nestalo, že ve snaze o řešení několika komplexních problémů jedním systémem vznikl program, který se v určitých předem těžko definovatelných situacích chová jinak, než se od něj očekávalo?
Datum vložení: 27.3.2005 3:51:24
Dobrý, Petře, Líbí ;)
Datum vložení: 7.4.2005 12:34:53
nemuzete nekdo nastinit, jak dostat data z vytvorenychh objektu pomoci CtreeNode class ??
Datum vložení: 9.4.2005 15:20:52
Ahoj, zajimal by me vas nazor na srovnani popisovane metody pro zobrazeni stromu s rekurzivnim pristupem s pouzitim jednoho selektu pro kazdou uroven pro pripad, kdy lze nekter vetve "zabalit" - tj neukazat jejich podstrom. Konkretne mi jde o situaci, kdy jsou zabalene vsechny vetve, krome te, na niz lezi prave zvoleny uzel. V pripade vami popisovaneho reseni, by se do dotazu vlozila podminka, aby vsechny rozbalovane uzly mely takove left a right indexy aby se do nich vesel ten zvoleny uzel. Cili databaze by musela projit vsechny uzly a urcit zda obsahuji ten aktivni. No a ted prichazi moje otazka: Pri pouziti rekurzivniho volani dotazu klasickym pristupem s ukazatelem na parenta, by bylo treba udelat jen nekolik jednoduchych dotazu, kde by se dalo vyuzit vhodneho klice. No a hlavni vec, co me zajima: o kolik je jeden slozity dotaz vyhodnejsi nez nekolik jednodusich, pouzije-li se pripraveny parametrizovany dotaz. Mirek.
Datum vložení: 16.9.2005 18:49:48
dělám stromové menu, které je uložené v db mysql. Vybral jsem si první fci z tohoto článku, ale nejde mi jí předělat, tak aby vypisovala data v tomto formatu <ul> <li>o nas</li> <li>ahoj <ul> <li>a</li> <li>b</li> </ul> </li> <li>blee</li> </ul> Pomůžete mi někdo?
Datum vložení: 14.7.2007 13:26:51
Pro ty, co by měli problém s generováním ul-li stromu. Řešil jsem tento problém pomocí vygenerování syntaxe pro Texy a zpracováním texylou: http://texyla.jaknato.com Jedná se jen o malou úpravu prvního příkladu: function strom($parent = 'null', $level = 0) { static $kod; $result = mysql_query("SELECT <id< as <ID<, <nazevUkaz< as <NAME<, <nazevSeo< FROM <clanky< WHERE <predchoziId< " . ($parent == 'null' ? ' IS NULL ' : ' = ' . $parent)); $level++; while ($row = mysql_fetch_assoc($result)) { $kod .= "\n" . str_repeat(" ",($level - 1)) . '- ' . $row['NAME']; strom($row['ID'], $level); } return texyla($kod, 'admin'); } Texyla je AJAX nad Texy2 s tím, že php rozhraní lze využít na zpracování vstupních textů.
Datum vložení: 17.1.2006 15:40:12
Ja jsem to udelal tak, ze pouzivam cachovani serializovaneho podstromu, ktere ukladam do databaze do LONGTEXTu k odpovidajicimu zaznamu. Tabulka stromu sice narostla z 57 kB na 1MB, ale rychlost generovani webu se zvedla - misto 714 dotazu (tolik je tam uzlu) staci jeden. Cache si vzdy pri importu dat promazu.
Datum vložení: 18.1.2006 7:19:44
To je samozrejme spravny postup, ale hodi se spise pro menu atd. Data, ktere se mene casto meni.
Datum vložení: 8.2.2006 16:28:19
Zdravím, posílám odkaz, který osvětluje snad všechny potřebné metody získávání/změny dat u posledního příkladu (vkládání, mazání, výběr rodičů, následníků, úrovně zanoření,...). Pro mé účely je tato metoda zcela ideální, poněvadž mi nestačí jen získat menu, ale potřebuji znát i další atributy navázané (a hlavně dynamicky měněné = přístupová práva s dědičností) na předchůdce/následníky. Jako vylepšení podle mého nepříliš náročné na prostor a neodporující relačnímu principu vidím pevné uložení hloubky zanoření do dalšího sloupce. Nemusí se tak vykonávat poměrně náročné zjišťování levelu, když chci zjistit prvky na stejné úrovni (ve stejné větvi). Samozřejmě je to pak další věc, kterou je nutno ohlídat při změně struktury. http://dev.mysql.com/tech-resources/articles/hierarchical-data.html Jinak díky za článek, myslím, že dobře shrnuje danou problematiku, ať už byl inspirován jinde nebo ne!!
Datum vložení: 25.2.2006 15:31:42
ahoj, mám dojem, že první varianta má být v tomto tvaru: function getTree($parent, $level) { $result = mysql_query('SELECT * FROM TREE WHERE PARENT_ID='.$parent); $level++; while ($row = mysql_fetch_assoc($result)) { echo str_repeat(" ",$level).$row['NAME']."<br />"; getTree($row['ID'], $level); } } Jde o tu inkrementaci proměnné $level. Čus Kapčus
Datum vložení: 3.4.2006 20:27:22
Trapim sa ako vyriesit zmenu poradia v menu - cize sipkami hore, dole urcovat poriade. Prosim o radu ako to riesit. Dakujme
Datum vložení: 9.5.2006 19:43:14
pekny clanek hodne mi pomohl ale potreboval bych poradit jeste s necim nejsem zrovna nejdokonalejsi programator a lamu si stim hlavu uz docela dlouho. jak mohu zaridit aby se rozbalovali jen urcite vetve tedy pokud budu chtit zobrazit treba vetev INTEL tak aby vetve AMD a PAMETI zustali uzavrene. dekuji vsem za pomoc
Datum vložení: 29.1.2007 11:11:47
Osobně používám něco takového: Polozka A | 1 Polozka AA | 1.1 Polozka AA | 1.1 Polozka AAA | 1.11 Polozka B | 2 Polozka C | 3 Polozka CC | 3.1 Pri výběru to seřadíte podle pořadového čísla, rychlovka ;)
Datum vložení: 19.7.2007 16:36:12
Ano, na první pohled šílené. Na ten druhý pohled to je geniální nápad :) (mám na mysli traverzování kolem stromu). Problémy s aktulizací nejsou až tak velké, rozhodně se dají vyřešit a možnosti při výpisu jednotlivých položek a hlavně určení cesty k nim jsou prostě super :) Škoda, že jsem toto řešení nenašel dříve :) Ušetřil bych si práci při programování drobečkových navigací apod. věcí :)
Datum vložení: 11.9.2007 21:40:37
Výše uvedený způsob je rozhodně nejlepší a můžu jej doporučit - sám ho rovněž používám.
Datum vložení: 24.3.2008 17:38:18
Bohužel tady není možnost větvit strom, např. co by to vypsalo teď? A | 1 AA | 1.1 A | 1 AA | 1.1 AAA | 1.11 Při nevětveném stromu je to ale rozhodně hodně rychlá varianta.
Datum vložení: 16.10.2008 17:12:14
lol, to co si napsal je s prominutim p*covina.. strom jde normalne vetvit A | 1 -AA | 1.1 --AAA | 1.11 --AAB | 1.12 -AB | 1.2 --ABA | 1.21 --ABB | 1.22 B | 2 -BB | 2.1 --BBB | 2.11 ---BBBB| 2.111
Datum vložení: 10.8.2007 16:43:26
Chytrá metoda, bezesporu. Bohužel jsem ale přišel na jednu zapeklikost, kterou s sebou nese a tou je přesun podstromu do jiné části stromu. V takovémto případě je přepočítávání LFT a RGT šílenost a zatím jsem nepřišel na způsob, jak by to bylo zrealizovatelné. Není totiž přesun jako přesun a pokud třeba přesouváme podstrom z levé části stromu doprava, je nutno přepočítávat jinak, než když jej přesouváme z leva doprava atp. Nezná někdo nějaké hezké řešení tohoto problému?
Datum vložení: 4.12.2007 1:39:24
Ja vim ze je to clanek starsiho data, ale jsou tam chyby .. prvni ukazka obsahuje chybne predavani levelu getTree($row['ID'], $level++); ma byt getTree($row['ID'], $level + 1); Pak se to neodsazuje spravne. funkci volame takto getTree(0,0); Nebo mi neco uniklo?
Datum vložení: 20.1.2008 14:44:22
Jak u třetí metody sřadit záznamy v každé kategorii podle názvů a ne podle lft? Josef
Datum vložení: 25.5.2008 23:14:56
No, pokud se nekdo rozhodne pro id,parent, level, order, tak verte, ze level je zbytecny. Jde to snadno dopocitavat tim, ze to vraci uz setrizene a odpada odporne pocitani a updatovani pri presunu. Osobne si myslim, ze se hodi jenom pro odsazni pro hromadny vypis a je celkem zbytecny (treba to jde osetrit divy) Jinak muj nazor je, ze vsechny nabalovaci moznosti jsou sice plne funkcni, ovsem mnohem slozitejsi - nuze, zkuste si presunou prizpevek nekde jinde. Hodi se mozna tak na forum ci GB. Ovcem na foru brutalne nedostacuje, protoze casem bud zabira kvanta mista, nebo je velice omezene (kdysi sem resil vybirani, ze se nabaloval na sebe timestampy, ale uz bych to neudelal nikdy)
Datum vložení: 2.1.2009 18:21:29
Na začiatok sa chcem poďakovať za článok. Zhodou okolností práve píšem bakalársku prácu na rovnakú tému, preto by som sa chcel spýtať, či by mi niekto nevedel poradiť vhodnú literatúru. Vyšlo niečo k stromovým dátam aj v češtine alebo slovenčine?, za odpoveď vopred ďakujem.....