to vse vypada tak hezky, ale v praxi je to nepouzitelne.
Praktickym prikladem je jiz zmineny kusovnik a ja nevim, kolik zde pritomnych teoretiku grafu jiz bylo v nejakem podniku s podobnou problemtikou konfrontovano - ale jestli je parez stromem, to se to keca...
V praxi nejde o tupe prochazeni nejakeho stromu nebo zobrazeni v nejakem VB-tree-controlu - na to by znazornene mechanismy (odvisle od nejake konkretni databaze) jakz tak stacily s potem v tvari.
Pri rizeni a planovani vyroby se samozrejme zada vice - pri prochazeni stromu se musi rozhodovat jestli se nejaka podskupina rozlozi nebo ne, podle jakeho mechanismu se ma rozlozit, bude dany mechanismus platit od toho okamziku az do konce rozpadu na dane urovni apod..
Zde se pote setkavame s nasledujicimi problemy:
- nekdo musi uvedenou situaci namodelovat. To je tak komplikovane, ze to dokazi jen velice zkuseni jednotlivci - v kolika projektech se tito lide nachazeji?
- podari-li se to uz namodelovat, musi jini s modelem pracovat. Protoze tito ostatni nemaji takovy abstraktni aparat, dochazi neustale k dotazum na modelovaciho-guru, ktery vysvetluje neustale to same, protoze zbytek kolegu to neni s to pochopit (sam v projektu zazil)
- na zmeny ve strategii pro praci s hierarchii je mozno uz rovnou zapomenout, protoze vesmes chybi ten guru, ktery by sdelil, co si pri navrhu myslel.
Ten kdo docetl az sem by se mohl ptat, co tedy pouzit, kdyz to popsane je nesmysl. Odpovedi jsou v diskuzi - pouzit hierarchickou databazi a je li predepsanna SQL, tak na aplikacni urovni bez toho aby se vymyslelo neco v relacnim modelu, ktery prave v techto ulohach ukazuje, ze neni schopen smysluplne zobrazit prakticky svet...
Praxe je jeden neresitelny pripad, deset obtizne resitelnych a 89 snadno resitelnych ze sta :-). Zminovane techniky jsou pro tech 89%. Ve vasem pripade bych skoro i pochyboval, zda by se daly pouzit ulozene procedury. I kdyz neco by slo, muselo by se to vyzkouset. Ale pochybuji, ze by to zvladal PostgreSQL a Potemkinovym patchem.
Inteligentni jedinci se nachazeji skoro vsude. Jde je jen o to je motivovat, by se chovali inteligentne. Nebo nastavit procesy, byrokracii tak, abych mi stacilo par geniu a banda poskoku, napr. projekt Apollo. Na to abyste dobre navrhl model musite byt budto Pan Buh, ktery vi co bude, nebo mit proste stesti. A stejne musite opakovane zjistovat jestli jste se svym navrhem trefil do vkusu, potreb. Po pravde receno, nikdy jsem nemel problem s inteligenci mych kolegu - budto mam stesti a nebo to nebude se mnou nijak slavny :-). Horsi je to se mnou. Cim mate mene duvtipne spolupracovniky, tim jim to musite lip vysvetlit. Je to sice trochu ztrata casu, urcite jista namaha, na druhou stranu problematiku nejlepe pochopite tak, ze ji bude nekomu vysvetlovat. Taky muzete pripravit dalsi rozhrani, trochu odstinujici uzivatele od komplexnosti systemu. A nekdy to holt udelat jednoduse nejde.
Relacni SQL databaze se pouzivaji celkem bez problemu, a nerozsirily by se pokud by nebyly prinosove v plusu. Zakladem je ale vedet, co chci udelat a jak to udelat. Je urcite velky rozdil v navrhu. Pokud jste delsi dobu pracoval s nerelacnimi databazemi, tak proste myslite jinak (bez urazky). Ja bych mel zase problem pracovat s hiearch. databazemi. Nez jsem se naucil pouzivat SQL tak mi to nekolik let trvalo. Ale treba k Foxce se kterou jsem zacinal uz bych se nevratil. Prolog uz asi nikdy nepochopim, a kdyz se divam na kod v lispu nebo v Smalltalku tak si rikam, ze to je vec, ale jsou to bohove :-), kdyz to zvladaji.
Samozrejme, to co jsem tady predvadel je to nejjednodussi, co se da predvest. Rozhodne to nevypovida o moznostech RDBMS. Zrovna v teto oblasti se jednotlive RDBMS dost lisi. S rekurzivnima dotazama (Common Table Expression) se toho necha delat hodne, a dost mozna by to zvladlo i Vase pozadavky. Ale mate pravdu, ze to je tezsi vymyslet. Ono uz pouzivat vazane SQL poddotazy neni nic jednoducheho.
Tvuj prispevek mi pripada dost zmateny.
My jsme zpracovavali 200000 kusovniku sekvencne
uz v osmdesatych letech. Nemeli jsme to naklicovane,
ale museli jsme strom pekne projit.
Navic, SQL databaze je zabehnuta na evidence vseho druhu a
jen nekde je potreba ulozit stromovou strukturu - zdroje, dealeri, organizacni strukturu apod.