Ovo mu ga dođe na isto, zar ne?

Imam jedan veliki upit koji ima recimo 4-5 join-ova i onda u where ima nekih 3-4-5 uslova od kojih je jedan grad="beograd", pri čemu nad kolonom grad nema indeksa.
ILI, da prethodno uradim select id from gradovi where grad="beograd" i onda u ovaj veliki upit stavim where grad_id = id_koji_mi_vrati_ovaj_"mali"_upit.

Da li je neka varijanta od ove dvije značajno bolja, jer nešto sad kontam da bi to u stvari na isto trebalo da izađe kad se gleda na kraju?

Potpis

Beneath civilization's fragile crust, cold chaos churns...

zaje1234 tyler a ? veliko je vrlo subjektivna stvar, samo pitaj bolju
polovinu :D

druga varijanta sigurno ne valja zato sto nemas index po grad sto znaci
da ces raditi full table scan
u prvoj varijanta ako bilo koji od 5 uslova ima index suzice kolicinu
date koju server mora da procita znaci bice brze

tako da ne, nikako nisu isti, i ne, nikako drugi nije bolji

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

:-)

Samo malo još da pojasnim situaciju. Trenutno ova tabela sa gradovima nema više od 100 redova, i u sadašnjoj situaciji to mi nije problem i ne pravi mi nikakvu razliku u performansama tako da je možda bezveze da upadam u "premature optimization" ali ipak bih volio da to sad odmah riješim jer očekujem da će ipak u nekoj malo daljoj budućnosti imati značaja i ovo.
Takođe, postoje još 2 (regija, kategorija) tabele koje imaju istu ulogu kao i ova sa gradovima i koje će se dodavati u where na isti načim samo što one imaju još manji broj redova <10.

Potpis

Beneath civilization's fragile crust, cold chaos churns...

Ja mogu da stavim indeks na sve ove varchar kolone (grad, kategorija..) i stvar sređena, zar ne?
Nego nešto izbjegavam da pucam indekse kako mi gdje padne na pamet, pogtovo ako ima neko "elegantnije" riješenje.

Potpis

Beneath civilization's fragile crust, cold chaos churns...

Prvo, nije mi jasno šta će ti dve tabele, jedna u kojoj je grad, a druga u kojoj je regija. Po meni (a ne znam šta radiš) grad pripada nekoj regiji. Ne znam kako se tu uklapa kategorija.
Drugo, ako je kategorija neki tvoj šifarnik, nije mi jasno šta će ti ID. Recimo, kategorije mogu biti 1, 2, 3, "žuto", "belo" pa mi nije najjasnije zašto ti je bitno da stoji u nekoj tabeli id_kategorije=323 ako može da stoji "žuto".
Treće, ne znam zašto u kveri ulaziš sa "beograd", a ne sa id grada. Moguće da je u pitanju neki kveri koji i onako dugo traje, pa ne vidim da bi indeksiranje male tabele popravilo vreme izvršavanja. Ako je u pitanju neki report, onda ima smisla da jedan od ulaznih parametara može da bude id umesto naziv grada. I tako kod pravljenja reporta više vremena se troši na formatiranje stranice nego za full scan male tabele...

Potrebne su mi regije i na drugim mjestima a ne samo u kontekstu vezanosti za grad pa zato mora izdvojena tabela, isto tako i gradovi. A i da bih izbjegao redudantnost gdje bih za nekoliko gradova morao da upisujem istu regiju.
Što se tiče kategorija, nisam te skroz shvatio. Ti predlažeš da skroz izbacim id-jeve i da imam samo naziv kategorije kao id?
Treće, u kveri ulazi beograd jer mi tako dolazi taj podatak. Baš to je i bilo moje početno pitanje. Da li da taj podatak koji mi dolazi u obliku stringa prethodno pretvorim u njegov id pa onda radim upit ili da prosto pustim taj string u upit i ne bakćem se sa traženjem njegovog id-ja.

Potpis

Beneath civilization's fragile crust, cold chaos churns...

Pa vidiš da sam stavio gomilu if-ova u svoj odgovor. Ne znam koji je to problem koji ti rešavaš.

Da li se, recimo, baviš OLAP-om. Ako se baviš ili si upoznat sa opštim konceptima, znaš da dimenzija može da ima hijerarhiju.

Na primer, danas je 17. oktobar 2015. godine. Ako je datum dimenzija, tu možeš da napraviš hijerarhiju dan-mesec-kvartal-godina, pa ne moraš da stavljaš da je 17.10.2015. godine datum koji je u 17. dan u 10. mesecu, 4. kvartala 2015. godine. Takođe i 18.10.2015. godine je u istom mesecu istog kvartala iste godine kao i 17.10. pa to nikome ne smeta.

Isto tako, ako je grad beograd, odmah imaš regiju, državu, kontinent, već šta ti treba.
I kakve veze ima to što se regija ponavlja. Gradovi se vrlo retko sele iz regije u regiju. Osim toga, gradovi i retko menjaju imena (menjaju, ali retko) pa je i tu pitanje da li ima smisla da se stavlja ID.

Na ovaj način, kada imaš ID, a nemaš indeks nad gradom, kako obezbeđuješ da nemaš mesto "Ada", ili "Beograd", "BeOgRaD" pod više ID-ova?

jbg tyler, da se vratim na pocetno pitanje, el ti nas za123 :D ..
mislim nisi od juce na forumu, znas da je extra tesko dati validan odgovor na nedovoljno definisano pitanje .. a gledanje u kristalnu kuglu nikad ne izadje na dobro :D

ja cu ti odgovoriti sa par opstih mesta koja 99% vec znas al ajd mozda neko nesto nauci a mozda i tebi pomognu da dodjes do resenja, pretpostavljam da imas razlog zasto ti je pitanje "vague"

- upiti treba da budu uglavnom vezani za ID-e a ne za stringove
- ID od stringa najbolje raditi preko kesiranih mapa (kesiras kroz lokalne mape ili externo kroz memcached i slicno)
- upit koji ne koristi index radi full table scan, full table scan cita celu tabelu, ako je vec citas iscitaj i sve ostalo odma i filtriraj iz tabele
- treba da izbegavas full table scan gde god mozes (kesiraj u lokalne mape, memcached, dodaji indexe..)
- upit koji koristi kompozitni key je skoro uvek brzi (i manje smara server) od upita koji koji koristi vise kljuceva
- pravi kompozitne kljuceve!!!
- redosled kolona u kompozitnom kljucu pravi veliku razliku

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

@djoka_l
nažalost nisam upoznat sa tim konceptom OLAP-a, ali pogledaću malo.
Što se tiče "Ada", ili "Beograd", "BeOgRaD" to riješavam kroz aplikaciju i korisnici ne mogu da proizvoljno unose gradove. Predefinisani su.
U pitanju je veb aplikacija, ništa posebno briljantno. Više me interesovalo kao generalno šta je bolje za ovaj primjer što sam dao.

@bogdan
kapiram te, ali ne čini mi se da je pitanje toliko nedefinisano.
Malo ću da se udubim u kompozitne ključeve, ali to mi je uvijek bilo malo komplikovano baš zbog toga što je redoslijed bitan i toga što imam mnogo spajanja tabela gdje mi se čini da bi se samo zakomplikovala situacija i usporila sa kompozitnim ključevima.
Hvala :-)

Potpis

Beneath civilization's fragile crust, cold chaos churns...