pocet pristupu s indexovymi souboy s bitovou mapou

[JirkaL]

Asi mi to ted vubec nepali, ale nechapu, jak by mohl mit ten strom vysku 2. Pokud m = 60, tak krome korene musi mit kazdy uzel minimalne 30 potomku, tedy v jakemsi "minimalnim" pripade bude mit koren dva potomky a kazdy z nich 30 potomku => to mame 60 uzlu na listove urovni (pokud vyska = 2) a kazdy z techto uzlu ma minimalne 29 klicu => nas strom ma 1740 klicu.

Podle mne by mel mit vysku 1..

Celkom uspesne ma tu zamotavate. Ak som dobre pochopil, tak hore co je uvedene vyska dva vlastne nie je vyska dva ale jedna (koren sa do vysky nezapocitava). Dva z toho pohladu, ze potrebujes dva pristupy. Takze ak ma koren potomkov a ti maju potomkov, to je v skutocnosti vyska dva, nie tri. Takze tvoje vypocty su dobre a myslene to bolo rovnako, len nie podla definicie:) Alebo aj ja to vidim inak?

Jo, presne tak jsem to myslel Jen abychom sjednotili terminologii.

[fissie]

A taky pozor na ty bitmapy. Na nasem cviceni tenhle tyden nam vyucujici potvrdil tohle... Ta bitmapa se sklada z tolika vektoru, kolik hodnot ma. A kazdy ten vektor se umistuje obvykle zvlast
...

No a kdyz mas bitmapu, kde se ti vektory pro vsechny mozne hodnoty vejdou do 1 bloku (na 1 zaznam pro 1 hodnotu potrebujes 1 bit)?
Napr. tech 597 zaznamu * 6 hodnot = 3582 bitu = cca 450 bajtu ...

Zaprve v te uloze nebyla specifikovana velikost bloku, takze kdyz bude tech zaznamu v zadani o neco vic, tak uz mas smulu, protoze blok muze mit klidne treba 512B . Todle je prave otazka, proc bys to tak delal. Ve chvili, kdy ti to vytece z jednoho bloku, tak to rozdelis na dva bloky, kazdy po trech vektorech, pak ti to pretece znovu, rozdelis to na tri bloky po dvou vektorech... etc? Nejak si moc nedokazu predstavit, ze by to nejaka realna aplikace delala.

Samozrejme, v pripade, ze bys mel vzdycky v kazdym bloku kus kazdyho vektoru, tak pro prvni blok (ostatne i pro kazdy dalsi) se to bude chovat presne tak, jak ty popisujes...

[qwyxyo]

Zaprve v te uloze nebyla specifikovana velikost bloku, takze kdyz bude tech zaznamu v zadani o neco vic, tak uz mas smulu, protoze blok muze mit klidne treba 512B

Neviem ci som si to odniesol z cvika alebo som to niekde iba zachytil, ale pokial nemas velkost bloku explicitne urcenu, berie sa asi 4096B na blok.

[twoflower]

A taky pozor na ty bitmapy. Na nasem cviceni tenhle tyden nam vyucujici potvrdil tohle... Ta bitmapa se sklada z tolika vektoru, kolik hodnot ma. A kazdy ten vektor se umistuje obvykle zvlast (jsou tak drazsi inserty, ale je levnejsi vyhledavani) - tudiz na insert bude treba prave tolik cteni a prave tolik zapisu, kolik je moznych hodnot daneho atributu. Pokud by se ty bitmapy umistovaly prokladane (pro kazdy vektor vyhradit v kazdem bloku vyhradit stejnou cast), pak pro jedno vyhledavani je nutne nacitat uplne celou bitmapu... Vzhledem k tomu, ze insert je vetsinou mene castejsi nez select, tak je asi lepsi ten prvni pristup.

Mohl bys prosim vysvetlit, co presne myslis tim "kazdy vektor se umistuje obvykle zvlast"? Tj. jeden vektor do jednoho bloku? A proc bych pak mel mit levnejsi vyhledavani?

[Návštěvník]

Jak by se to lisilo, kdybych mel index-sekvencni soubor misto indexovaneho?

Dejme tomu ten INSERT:

Na nacteni listu opet 2*(s + r + btt)
Tam zjistim adresu ciloveho bloku, kam by mel zaznam patrit, nactu ten blok v primarnim souboru: s + r + btt
Zjistim, ze je plny. Ted ovsem nemuzu jako u indexovaneho souboru proste zapsat novy blok na konec, ale protoze primarni soubor musim udrzovat setrideny, mel bych asi posunout vsechny bloky a zaradit novy...

Pak jeste update B-stromu podobne jako u indexovaneho souboru.

Jak by se to pocitalo? Jde hlavne o ten hnusny update primarniho souboru.

[twoflower]

Jak by se to lisilo, kdybych mel index-sekvencni soubor misto indexovaneho?

Dejme tomu ten INSERT:

Na nacteni listu opet 2*(s + r + btt)
Tam zjistim adresu ciloveho bloku, kam by mel zaznam patrit, nactu ten blok v primarnim souboru: s + r + btt
Zjistim, ze je plny. Ted ovsem nemuzu jako u indexovaneho souboru proste zapsat novy blok na konec, ale protoze primarni soubor musim udrzovat setrideny, mel bych asi posunout vsechny bloky a zaradit novy...

Pak jeste update B-stromu podobne jako u indexovaneho souboru.

Jak by se to pocitalo? Jde hlavne o ten hnusny update primarniho souboru.

Nezapsalo by se to spis do nejake oblasti preteceni misto prerovnavani celeho souboru?