[ Sportster @ 13.11.2005. 23:02 ] @
Dakle...

Data mi je šema baze podataka, koja je u nekom trenutku dobijena iz modela objekata i odnosa.

posle odrađene redukcije i redundanse šeme (restruktuiranje), treba da uvedem indekse.

e sad, posto sam ja teški početnik, zanima me kojom logikom uvodim indekse, tj. kako biram tabelu nad kojom cu je uvesti.

primer :

Privatna lekarska odrinacija. Pacijenti mogu biti : gradjanstvo, ili radnici te ordinacije (ne lekari). Pacijenti zakazuju termine. Zakazan termin moze biti ostvaren ili neostvaren. U terminu pacijent ima 1 ili vise tretmana prilikom koga mu lekar pruza uslugu. Po okoncanju TERMINA, pacijentu se ispostavlja racun sa STAVKAMA, od kojih svaka stavka odgovara jednom TRETMANU. Racun se placa U CELINI, odmah ili naknadno.

ORIGINAL ŠEMA :

pri cemu je [...] = primarni kljuc

LEKAR([IDLek], Ime)
USLUGA([IDUsl], Naziv, Cena)
PACIJENT([IDPac], Naziv, Adresa)
RADNIK([IDPac], MatBroj)
TERMIN_ZAK([IDTer], Datum, Vreme, IDPac)
TERMIN_OST([IDTer], Trajanje)
TRETMAN([IDTre], MedPod, IDLek, IDUsl, IDTer)
RACUN([IDRac], Datum, IDTer)
STAVKA([IDSta], Iznos, IDTre, IDRac)
UPLATA([IDUpl], DatumUplate, IDRac)


upit nad tabelom : Ukupan prihod po uslugama.

1) Redundansa => USLUGA([IDUsl], Naziv, Cena, UkPrihod)

Potreban je TRIGGER AFTER INSERT ON UPLATA koji radi sledece:

- Iz tabele RACUN se dobija IDTer termina za koji je pacijent platio racun
- Iz tabele TRETMAN se dobija spisak IDTre svih tretmana koji su ostvareni u tom terminu kao i IDUsl usluga koje su tada pruzane
- Iz tabele STAVKA se dobijaju iznosi usluga pruzenih pacijentu za svaki od tertmana u okviru termina za koji je platio racun
- Za svaku od tih usluga se na vrednost polja UkPrihod odgovarajuceg reda tabele USLUGA dodaje dobijeni iznos.

---------------------------(ovo do sada je jasno)-----------------------------


2) Uvodjenje indeksa za gorenavedeni upit

CREATE INDEX ind1 ON TRETMAN (IDUsl) sort

CREATE INDEX ind2 ON STAVKA (IDTre) hash

CREATE INDEX ind3 ON UPLATA (IDRac) hash


PITANjE : kojom logikom se uvode ovi indeksi....i zastto je bas ovako odradjeno, tj za ovakav odabir tabela, jer meni pada na pamet 1000 drugih kombinacija.


+ pocetnik sam u svemu, a ovo je za ispit na etf-u....


unapred zahvalan.
[ broker @ 13.11.2005. 23:47 ] @
Najjednostavnije je da uvedes indekse na primarne kljuceve i polja koja se koriste zapovezivanje slogova u razlicitim tabelama.
[ Zidar @ 14.11.2005. 13:35 ] @
Nema tu sta da se bira. SVAKA tabela treba da bude indeksirana. Ako ti se ucini da imas neku tabelu kojoj naoko ne treba indeks, onda imas problem sa dizajnom. Lepo rece Broker - pocni od Primary i Foreign keys, pa vidi dalje. Sva polja po kojima ces raditi WHERE ili GROUP BY treba da su indeksirana, a svi PK/FK spadaju u ovu kategoriju, ali i neka druga polja svakako.

:-)
[ branimir.ts @ 01.12.2005. 14:43 ] @
Citat:
Zidar: Nema tu sta da se bira. SVAKA tabela treba da bude indeksirana.


Indeksiranje tabela se uvek radi naknadno i uglavnom zavisi od
-struktura upita koje izvrsavas (analiziraj preko kojih polja se obezbedjuju uslovi u tvojim upitima npr.
Code:
WHERE username='xxxxxx' and PayState > 1000 -polje 'username' je ocigledan kandidat za index itd )

-velicina tabela nad kojima izvrsavas upite

Naravno da gore navedeno nije tacno. Ima li smisla praviti ikakav index nad tabelom reda velicine 1000 slogova?

Pozdrav

[Ovu poruku je menjao branimir.ts dana 01.12.2005. u 16:51 GMT+1]
[ Zidar @ 01.12.2005. 17:05 ] @
Tacno kaze barnimir, na 1000 slogova ne mora uvek index. Ali i ne smeta. Prostor koji ce index na 1000 slogova da zauzme je beznacajan, pa nema puno stete. Ako odem malo u proslost, ne mogu da izbrojim puno slucajeva gde nam se server ugusio jer je bilo previse indeksa. Ali zato mogu da nabrojim mnogo slucajeva kada su stvari isle sporo zato sto nismo imali indekse. Pa ko velim, bolje je praviti gresku na stranu sigurnosti.

Doduse, moje tabele nisu 100,000,000 rekorda sa 2000 korisnika. Vise sam u okolini 3,000,000 rekorda i 500 korisnika i za sada sve radi. kad imamo problema, a desi se da ih imamo, oni su obicno neke druge prirode, nisu zbog postojanja previse indexa. Pa da batalimo cepanje dlake na cetrnaest delova. SQL ionako sam odlucuje kada ce i kako da koristi indekse, ako mu se naravno ne kaze drugacije.
:-)