hierarchie

[Korinek, Jan]

> > Hmm, tak to se asi skutečně nevyhneš vnořeným dotazům a v 
> konečném důsledku
> > omezení zanoření :-(((((
> > 
> > I když?
> > 
> > Umi ten tvuj stroj klauzule "where neco in" a having?
> 
>  Muj stroj je zatim MySQL (celkem pri tom trpim..) pak to bude asi

Tak to se nedivim :-)))

> PostgreSQL nebo Sybase. Takze 'in/having' by bylo. Jen bych 
> rad poznamenal, 
> ze toho budou cca stovky (mozna tisice) radek.

Hmm, s tim by snad MySQL problemy mit nemelo ...

> > No, to je jednoduchy, když potrebujes vyhledavat na urcitem 
> levelu stromu,
> > rekneme vsechny prvky na 5. urovni s danou podminkou, v 
> klasickem stromu
> > musis porjit vsechny nadrazene vetve ale v pripade pouze 
> "stromovych flagu"
> > (jejda, to si necham patentovat ;-)))) to mas 1 dotaz :-)
> 
>  To ale vybere 5. uroven ze vsech stromu, nebo ne? Jak 
> specifikuji ten strom
> (tedy maji-li to byt ve stromu 'psu' nebo 'papousku').  

Ten flag nebude tikitaklni, rekneme: Uroven 1 [ pes | papousek | ... ]
optimalne ciselnik

No a pak zadas where l1 == "pes" and l2 == "hnedy" a mas vsechny hnedy
cokly, jen to hvizdne, MySQL se po tom jenom oblizne :-)
V pripade, ze ti dojdou atributy, alter table zvirata ....

>  Taky mi jde o update, abych to nemusel vzdy slozite 
> precislovavat. (viz. 
> ten retezcovy model co jsem psal)

A hromadne precislovani, podle me jednoduche, jestli to webujes, udelej si
ciselniky na attributy a prezentuj je jenom externe :-)))


> 
>  Ale, asi nebudu mit vsechno najednou, bud to pujde snadno vyhledavat 
> (viz. ty retezce '1.2.1' apod.) a nebo to pujde snadno udrzovat.

A hierarchie, prvek je clenem atributy presne definovane skupiny. Dal uz
radis jenom podle sebe :-)))

Honza