[ MarkoBalkan @ 03.01.2010. 14:49 ] @
zapis index-a u b-tree mi je jasan.

kako se zapisuje kada imamo kompozitni index?

[ Comii @ 04.01.2010. 10:29 ] @
Kompozitni index može biti i klasterovan ili neklasterizovan, samo što za razliku od "običnog" index-a kompozitni index sadrži dve ili više kolona(maksimalno 16).


CREATE UNIQUE CLUSTERED INDEX Naziv_Indexa
ON [Naziv_Tabele] (Naziv_kolone1, Naziv_kolone2....)

ili

CREATE INDEX Naziv_Indexa ON [Naziv_Tabele](Naziv_kolone1, Naziv_kolone2....)



Što se tiče zapisa u b-tree on je zapravo isti kao kod klasterovanog ili neklasterizovan index-a, odnosno zavisi da li je određeno da kompozitni index bude klasterizovan odnosno neklasterizovan!



[ MarkoBalkan @ 04.01.2010. 11:22 ] @
Citat:
Comii: Kompozitni index može biti i klasterovan ili neklasterizovan, samo što za razliku od "običnog" index-a kompozitni index sadrži dve ili više kolona(maksimalno 16).


CREATE UNIQUE CLUSTERED INDEX Naziv_Indexa
ON [Naziv_Tabele] (Naziv_kolone1, Naziv_kolone2....)

ili

CREATE INDEX Naziv_Indexa ON [Naziv_Tabele](Naziv_kolone1, Naziv_kolone2....)



Što se tiče zapisa u b-tree on je zapravo isti kao kod klasterovanog ili neklasterizovan index-a, odnosno zavisi da li je određeno da kompozitni index bude klasterizovan odnosno neklasterizovan!


sorry, ali nisam to pitao i znam što je kompozitni index.

pitanje je kako se zapisuje kompozitni index u b-tree stablo.
znači kako se smještaju vrijednosti.
kad je jedan atribut u pitanju to ide normalno po pravilu.

da li se i kod kompozitnog vrijednosti smještaju jedna do druge ili kako?

ako imamo (2,3),(5,6),(6,2),(8,9),(2,4),(1,3),(3,9) -> ovo treba smjestiti u stablo.


[ bogdan.kecman @ 18.01.2010. 16:09 ] @
obrati paznju da "u memoriji" i "na disku" nije isto ... u memoriji imas b+ (koristi se za rdbms mnogo cesce od obicnog btree) .. na disku imas "sta god je programer odlucio da mu je najlakse da snimi / procita" ...

sve u svemu, myisam ti je najjednostavniji (daleko od toga da je najbolji) posto ima za svaku tabelu index u posebnom fajlu. Uzmes i kreiras jednostavnu tabelu sa jednim indexom i popunis je i onda pogledas kako izgleda myi fajl. generalno fajl ima na pocetku duzinu hedera, pa heder u kom pise kako indexi izgledaju .. i onda idu indexi ... cuvaju se u fajlu samo leaf vrednosti (ako se dobro secam) i generalno izgledaju za key (a,b,c,d) kao

a, offset na sledeci segment za ovaj nivo, b, offset na sledeci segment za ovaj nivo, c, offset na sledeci segment za ovaj nivo, d, pointer na podatak u myd fajlu,

i to u idealnom slucaju sortirano po a,b,c,d

malo sam bukvalizovao al to je generalno to. InnoDB to radi malo drugacije, pgsql jos drugacije, oracle skroz na drugi nacin etc etc etc ... u ramu skoro svi imaju b+, neki imaju nekoliko b+ u ramu a neki modifikacije b+ kako bi izbegli neke limite (koje npr mysql ima) ... pa onda imas dodatna komplikovanja za mvcc etc etc .. sve u svemu "najjednostavniji" nacin imas sa myisam-om (sa svim njegovim ogranicenjima, bez ikakvih "fancy fora" i slicno). Neki engine-i imaju razne fora (recimo fulltext key tog istog myisam-a, ili rrd key za neke storage engine ..) gde je sve ovo mnogo drugacije ... al u osnovi uvek je razlika sta je u ramu a sta je na disku