SQL i INDEX

Ovakoc, jesam li dobro shvatio…
Ako imam tablicu sa 1000 redova. Jedna od kolona je indeksirana i vrijednost joj može biti 1,2,3 ili 4. Recimo da su te vrijednosti ravnomjerno rasporedjene kroz svih 1000 unosa.

Ako ja radim pretragu prema indeksiranoj koloni gdje je ta vrijednost 1, onda je potreban broj operacija jednak kao da sam imao posebnu tablicu gdje postoji samo 250 redova??

Isto vrijedi za foreign key??

Sto si zelim zapravo razjasniti, …jesu li tablice sa enormno velikim brojem unosa problematične ako postoje vanjski ključevi koji isto tako imaju dosta vrijednosti. Recimo 100 000 korisnika i za svakog je vezano 100 komentara.
Ako su svi komentari pohranjeni u jednoj tablici, to je 10 000 000 redova…zvuci mi zastrasujuce :). Ali ako cemo gornjom logikom, i ako su komentari vezani preko vanjskog ključa za odredjenog korisnika, to je zapravo kao puno tablica sa malim brojem unosa? I struktura je sasvim ispravna?

U načelu da, iako pitanje nije baš dobro definirano (što bi bila “pretraga” skupa svih istih vrijednosti?).

Zbog toga što su podaci u strukturi indeksa poredani, omogućuju pronalaženje zapisa u broju koraka koji je reda veličine log2(N). Npr. log2(10000000) = 23.

No, primjer koji si ti dao, gdje na 1000 zapisa postoji svega 4 različite vrijednosti, u principu je primjer lošeg kandidata za indeksiranje, jer taj skup podataka ima malu kardinalnost - puno zapisa ima istu vrijednost. Ipak, o ovome ne davao općeniti sud, već razmišljao u kakvim bi se upitima i na koji način iskoristio takav indeks.

http://mattfleming.com/node/192

Strani ključ služi definiranju referencijalnog integriteta podataka i nema veze s ubrzavanjem pretraživanja.

Međutim, strani ključ jest ključ, tipično se stranim ključem veže na primarni ključ, a sigurno makar na alternativni. Svaki ključ ima maksimalnu kardinalnost, pa je u principu dobar kandidat za indeks. Zbog toga baze podataka tipično automatski generiraju indekse nad poljima koja su u stranom ključu. U najmanju ruku, strani ključ može pomoći u optimaliziranju plana izvođenja upita.

Foreign key - Wikipedia, the free encyclopedia

Poanta je uvijek u upitima koje vršiš nad bazom. Indekse se, a često i model baze, prilagođava vrstama pretraživanja koje ćeš raditi.

No, načelno govoreći, ne - nemaš problema s takvom situacijom, baze služe upravo tome, a za potrebe profiliranja uvijek možeš napuniti bazu ogromnim brojem generiranih podataka i istraživati da li ti performanse odgovaraju i što bi mogao učiniti da ih popraviš.

Aha, mislim da sam te skuzio…ja sam ipak drukcije to zamisljao. Indeksi su znaci poredani po svojoj vrijednosti, i onda algoritam uvijek cjepa na pola i gleda jeli trazena vrijednost s lijeva ili s desna? Mislim da bi to odgovaralo tvojoj formuli … onda mi je jasno zasto je bolje da index ima cim vise razlicitih vrijednosti.

Po tome strani ključ još više pridonosi kao index, nego sto sam ja zamisljao :slight_smile:
tnx

Da. To se zove binarno pretraživanje (binary search).

Ovisno u kojem smjeru ide, tj. tražiš li iz zapisa “djeteta” njegov (jedan i jedini) povezani zapis “oca” ili iz zapisa “oca” njegovu djecu. U ovom potonjem slučaju možeš opet imati svašta. Za taj aspekt razmisli o dva načina fizičkog ostvarivanja relacije “otac-djeca”: preko posebne tablice kojom se fizički modelira relacija ili na način da je primarni ključ oca podskup atributa koji čine primarni ključ djeteta.

Uf, s ovom zadnjom recenicom si mi dao razmisljati…ajmo se vratiti na konkretan primjer :slight_smile:

Imamo korisnike, i svaki korisnik posjeduje više komentara. Interes mi je kad poznam primarni ključ korisnika da pronadjem sve komentare vezane za njega. Korisnik je otac, komentari njegova djeca. Znaci imamo drugi slucaj ako sam dobro skuzio.
Prvi slucaj je jednostavan, iz komentara ocitamo kljuc koji vodi do samo jednog jedinog korisnika, a sad da vidim drugi slučaj…to je zapravo ono prvo što me je mučilo.

100 000 korisnika (neka svaki ima 100 komentara) =10 000 000 komentara. Tu nebi trebalo biti problema?? Ako sam dobro skuzio, problematika bi tek postojala kad bi broj djece bio relativno velik broj …dok sama veličina tablice gdje se nalaze djeca ostaje nebitna??

Za pronalazak svakog djeteta zapravo treba log2(N) koraka, ili pronalaskom jednog djeteta su pronadjena sva??

Ovo si zamislio kao jedinstvenu tablicu gdje se nalaze svi komentari vezani za jednog korisnika?
To bi znacilo da dinamički stvaram tablicu, nazovem ju tipa: $korisnikID.‘komentari’ ??

…ovo nisam skuzio sto mislis reci.

Riječ “pronalazak” nema zapravo nikakvog smisla.

Poanta je da imamo neki konkretni SQL upit koji zapravo nije ništa drugo nego stanoviti izraz u algebri skupova - u algebri skupova su operandi skupovi, a operateri poznate operacije nad skupovima: unija, presjek, razlika, produkt i sl.

Svaki upit zapravo opisuje kakvu složenu operaciju želimo provesti nad određenim skupovima. Tu operaciju treba provesti nekim redosljedom, krenuvši od prvog iili prva dva skupa (opratori su tipično unarni ili binarni), pa nastavljajući dalje preko međurezultata. Za to učiniti treba neki plan izvođenja. To je zadaća optimalizatora upita u bazi podataka - on treba iz teksta SQL naredbe producirati plan izvođenja koji će (a) dati traženi rezultat i (b) biti najbolji s obzirom na utrošak vremena i prostora.

Mi pomažemo optimalizatoru na način da mu pametno postavimo indekse i strane ključeve i tako omogućimo da u pojedinim koracima može primjeniti brže i efikasnije algoritme kojima se implementiraju operatori, umjesto sporijih. On nama pomaže tako što nam može za svaki upit objasniti plan izvođenja koji je on zamislio (naredba EXPLAIN u MySQL-u).

U principu, što želimo postići jest da u planu izvođenja bude što manje tzv. “full table scan” operacija ili drugih “sporih” operacija.

Dakle, sve ovisi koji točno upit želiš izvršiti.

Za ideju plana izvođenja vidi ovdje:

Kod ovako jednostavnog slučaja koji si ti uzeo za primjer, vjerojatno se nema što puno pogriješiti. Ali već pomoću ispisa plana izvođenja i u slučaju da iz komentara tražiš korisnika ili za korisnika komentare, možeš vidjeti neke operacije koje SUBP koristi pri realizaciji upita.

Kod kompleksnijih upita ti to može pomoći da uočiš razloge zašto se neki upit izvodi sporije nego je očekivano.

Iako, kod nekakvih tipičnih trivijalnih upita kakvi se koriste u web-programčićima i nema puno mudrosti.

[quote=“bozoou”]…ovo nisam skuzio sto mislis reci.[/quote]Npr. tablica KORISNIK ima primarni ključ PK(KORISNIK) := { IME_KORISNIKA }, a tablica KOMENTAR ima primarni ključ PK(KOMENTAR) := { IME_KORISNIKA, REDNI_BROJ_KOMENTARA }.

S druge strane možeš imati PK(KORISNIK) := { ID_KORISNIKA }, PK(KOMENTAR) := { ID_KOMENTARA }, PK(KORISNIK_KOMENTAR) := { ID_KORISNIKA, ID_KOMENTARA }. Ovdje koristiš 3 tablice. U ovom slučaju to nema smisla jer komentar pripada samo jednom korisniku, očigledno, pa bismo atribut ID_KORISNIKA imali direktno u tablici KOMENTAR, iako ono ne bi bilo dio primarnog ključa.

[quote=“bozoou”]Uf, s ovom zadnjom recenicom si mi dao razmisljati…ajmo se vratiti na konkretan primjer :slight_smile:

Imamo korisnike, i svaki korisnik posjeduje više komentara. Interes mi je kad poznam primarni ključ korisnika da pronadjem sve komentare vezane za njega. Korisnik je otac, komentari njegova djeca. Znaci imamo drugi slucaj ako sam dobro skuzio.
Prvi slucaj je jednostavan, iz komentara ocitamo kljuc koji vodi do samo jednog jedinog korisnika, a sad da vidim drugi slučaj…to je zapravo ono prvo što me je mučilo.

100 000 korisnika (neka svaki ima 100 komentara) =10 000 000 komentara. Tu nebi trebalo biti problema?? Ako sam dobro skuzio, problematika bi tek postojala kad bi broj djece bio relativno velik broj …dok sama veličina tablice gdje se nalaze djeca ostaje nebitna??

Za pronalazak svakog djeteta zapravo treba log2(N) koraka, ili pronalaskom jednog djeteta su pronadjena sva??[/quote]

ne mora te to zabrinjavati, 10 M komentra u tablici je puno, a opet nije nešto.
ja sam u jednoj tablici imao 400 milijuna slogova.


Copyright © 2020 WM Forum - AboutContact - Sponsored by: Mydataknox & Webmaster.Ninja