Vlákno názorů k článku Stromy od Marek Chlup - Děkuji za pro mne zajímavý článek. V praxi je...

Děkuji za pro mne zajímavý článek.

V praxi je možno se setkat i se stromy jiného typu, než je zde uvedený příklad. Jak jsem pochopil, v uvedeném příkladu má každé dítě maximálně jednoho rodiče. Tento předpoklad není například splněn u databáze kusovovníku výrobků, kde nějaká sestava často vstupuje do různých nadsestav. Chtěl bych se proto zeptat, zda umí s takovýmto stromem pracovat zde uvedené patche pro PostgreSQL? Pokud jde o "genealogický identifikátor" tak je zřejmé, že ten by si s takovým stromem neporadil.

S tym autorstvom by som si nebol tak isty, tazko sa to dokazuje :-)

Důkaz sporem by nemusel být tak těžký. :-)
--------
Nejhezčí matfyzácký ftip je:
Matfyzák - je krásný a inteligentní.
Matfyzačka - je taky krásný a inteligentní.

IMO, typicka matfyzacka reakcia :-)

Kusovnik soucasti je jedna vec.
Cely strom (rozpad kusovniku) je jina vec.
Pouziti konkeretniho kusovniku v soucasti nebo zakazce
by rozhodne nemelo byt ve stejne tabulce.

Mýlíte.se. Uzel stromu musí mít sice jen jediného předka - mezi ním a potomky je relace 1:N - ale to neznamená, že OBSAH některých uzlů nemůže být shodný. Předpokládám, že i když se stejná podsestava objevuje ve více sestavách, každý kus můžete zamontovat pouze do jediné z nich.
Předpokládejme, že každý záznam obsahuje vlastní jedinečný identifikátor a identifikátor předka. Jde vlastně o identifikátory uzlů, které definují strom - ale o vlastním obsahu uzlů neříkají vůbec nic. (Jedná se pouze o vazební identifikátory). Pokud se tatáž podsestava může opakovat vícekrát v různých kontextech, lze to řešit stejně, jako ve všech obdobných případech tohoto typu. Dalším prvkem záznamu bude identifikátor obsahu (tedy sestav) a pro vlastní sestavy vytvoříme číselník, ve kterém se už každá objeví pouze jedenkrát. Ke každé sestavě z číselníku snadno zjistíme všechny výskyty a ke každěmu z nich všechny předky i potomky. Stačí na to operace join.

Zdravim. Doufam, ze diskuse neni mrtva. Cetl jsem pomerne pozorne vsechno, co bylo napsano, ale nenasel jsem to, co jsem hledal. Naproti tomu jsem nasel to, co je problemovym uzlem ve Vasi debate. Ja to podam z jine strany. Mam pred sebou velke datove soubory, ze kterych bych chtel ziskat prehled o strukture. Nevidim, jestli je to strom, nevim do jake miry jsou data konzistentni a mam to zjistit. Podobne to je, kdyz znam priblizne strukturu, a hledam napriklad chybu. Vzdy musim nejak zacit, a strukturu dohledavat. Neznam rodice, neznam deti. Narazim na uzel a jdu podle nejake uvahy. Kdyz nebude spravna, zkoriguji, rozsirim dotazy a k tomu musim vytvorit doslova sit, ktera je ve vysledku tabulkou s mnoha udaji. Tohle je to, co je jadrem problemu. Je to rychla zmena vazeb, prohledavani na nekolika stupnich s prislusnou strukturou, ktera zahrne vsechny postupne nalezane vztahy. Uplne bezne se tak setkavam s resenim na urovni analyz vztahu M:N. Koketuji uz dost dlouho s ruznymi databazovymi systemy. Uznavam, ze asi nejlepsi je CACHE (byl jsem jednou na Cache Entree a dostal jsem zdarma obed), ale ani tento system si neporadi. A tak uz hezky dlouho hledam mechanizmus, ktery by tohle umel. Vysvetlim proc hledam takova reseni. Nedavno se na mne obratil jeden clovek, jestli bych dovedl vybudovat strukturu mnoziny 366^6. Jednim ze zakladnich predpokladu je porovnani 6^6. V prime souvislosti tedy astronomicke vetveni, ke kteremu je potřeba realnou databazi + tezebni mechanizmus. A ted se ptam ja. Nedoslo k nejake zmene od aktualni diskuse na toto tema? (Ja problem staticke supertabulky vyresil, a lze ji realne budovat - postupne generovat a rozsirovat, jen nemam predstavu jestli nahodou nedelam neco, co nekde funguje a kdyz tak jak? - odezvy ap. ochrany neresim, jen struktury, logiku skladu a tezby z pohledu limitniho zadani.) Dekuji za odpoved.