Htedoh da sve spojim u jedan post, ali ne vredi, idemo redom:
Citat:
|
Originalno napisao bojan_bozovic
Palo mi je u oci da zbog DELETE upita mozete imati primarne kljuceve koji nisu po redu, tj da RDBMS ne moze da vrsi binarnu pretragu po primarnim kljucevima = mora da prolazi kroz sve recorde - imate ih milion - milion. Idealno je da se izsortira pa vrsi binarna pretraga, ali to ne moze ako svi kljucevi nisu prisutni, tj imate bar jedan koji fali+dobro je da su po redu ako ih mnogo ima.
|
Apsolutno netačno. Kod svakog RDBMS postoji indeks nad primarnim ključem, koji je u formatu B stabla najčešće i koji se ažurira kako se menjaju slogovi. Ono što je bitno je da kada se koristi indeks ovog tipa, za operaciju pretraživanja (nalaženja sloga) za dalju operaciju nikada ne treba više od log(N) u vremenu - što jako sporo raste u odnosu na broj slogova u tabeli.
Citat:
|
Originalno napisao bojan_bozovic
Flatfile db koji je dobro dizajniran uz binarnu pretragu ima da bije SQL kad je pretraga po primarnim indeksima po sredi - a za sve ostalo ne moze biti sporija jer takodje mozemo da napravimo virtuelnu tabelu, izsortiramo po koloni i vrsimo binarnu pretragu. Naravno da za komplikovaniji upit (dovoljno je WHERE NAME="Pera") mora da se prolazi kroz celu bazu. Zeleo bih malo da prodiskutujem o ovome, mada ne spada u SQL vec dizajn samog RDBMS. Naravno, ovde mislim na flatfile db koji nije na Perlu ili sl. jezicima vec npr. C/C++
Edit: prakticno pri trazenju po primarnom kljucu ne moze da otpadne sortiranje, sto je problem za veliku bazu. Mnogo bi bilo bolje da nema uopste DELETE upita i da su indeksi po redu.
|
FlatfileDB? Koji je dobro dizajniran uz binarnu pretragu? Pa ti implicitno radiš isto što i RDBMS - imaš podatke (FlatFile) i indeks (sortiran binarno) i koristiš indeks da nađeš slog; samo što je
daleko lakše dodati novi slog na kraj tabele i njegov ključ u b-stablo indeks nego dodati novi slog u FlatFileDB, jer ovaj FlatFile u najgorem slučaju moraš da sortiraš ceo.