Zanima me koliko bi bilo opterećenje servera kad bi radio ovakav sql.
Imam glavnu tablicu koja sadrži link. Ostale 3 tablice sadrže podatke o linku kao što su (popularnost, bodovi…)
Svaki put kada korisnik otvori stranicu pokrene se sql koji uzima do 5000 podataka max, za svaki od njih prikupi podatke iz 3 druge tablice, pozbraja, sortira i onda prikaže korisniku
Zvuci kao jako losa ideja?
Sta se ne moze taj upit spremiti u cache? Podaci su dinamicni?
Nemam ideje kako drugačije, jer ti bodovi se daju dinamičko, tj. ljudi mogu tim linkovima davat bodove i još par stvari koje se trebaju zbrajat tako da posjetitelj svaki put dobije osviježene podatke
zvuci kao losa ideja
ili ti tablice nisu optimizirane i nisu u ok korelaciji jedna s drugom, ili ti queryi nisu optimizirani, zbrajanje i sortiranje se moze i treba rijesiti unutar querya
a ako vec nemozes querye optimizirat, onda svakako podatke spremiti nekako da se ne radi query svaki puta
Imam samo 4 tablice. Mislim da sam dobro postavio primary <--> foreign key relaciju i da mogu u jednom query to sve napraviti.
No mene zanima kad bi u jednom query-u to napravio za eto 5000 podataka kako bi se to odrazilo na server. Ako npr. 100 korisnik dođe i otvori stranicu, za svakog korisnika se mora taj query odradit da pokupim i prikaže podatke
A da li se mozda moze napraviti tako da se rezultat query-ja spremi u cache, i taj se cache osvjezi tek kada netko dodjeli dodatne bodove.
U svakom bi slučaju bilo zanimljivo napraviti cache. Jednostavno možeš napraviti privremenu tablicu iste strukture kakvu ima rezultat upita. Vrlo ćeš vjerojatno imati višekratno veći broj zahtjeva očitanja rezultata, nego mijenjanja podataka, što je tipično za web-okružje, pa bi to moglo imati pozitivne efekte na performanse. Ali treba imati na umu scenarij u kojem bi posjetitelji podjednako aktivno mijenjali podatke, kao što ih i očitavaju (to ovisi o tome o kakvoj se aplikaciji radi) - to je nešto što ovdje ne znamo.
Ali najbolji način ti je da si upit napišeš, tablice napuniš nekim generiranim podacima i istestiraš kako stvar radi. Znači, trebao bi napisati program koji bi ti generirao testne podatke (uvijek korisno), jednu jednostavnu web-stranicu za dohvat podataka i mjerenje vremena izvođenja i eventulano si pomoći nekom aplikacijom za testiranje opterećenja:
Ovo ti zvuči kao idealno rješenje. Ili, ako imaš već jako puno posjeta onda niti to nije baš najpametnije nego odradiš cron-job koji će pokupiti podatke i kreirati statičku stranicu s tim podacima (cache), i onda je ta stranica ono što prikazuješ korisnicima. Negdje staviš tooltip ili malu napomenicu da se rezultati osvježavaju svakog punog sata i da možda nisu najtočniji prikazani trenutno (nešto kao što Youtube radi na videima gdje je velika posjećenost - ne prikazuju real-time rezultate već ima oscilacija).
I onda praktički si se limitirao na jedan poziv bazi podataka, jedan query koji hvata 5000 podataka, jednom na sat. 24 puta dnevno. Što nije loše, a rezultate imaš optimalne (male varijacije u prikazu tih rezultata u odnosu na stvarne).
Kao malu napomenu bih ti dao da dobro promisliš koliko ažurni ti prikazani podaci trebaju biti - ako ne mora biti cron svaki sat, već ako može svaka dva sata - gledaj to kao veliku uštedu, to je 12 puta dnevno za razliku od 24, duplo manje resursa trošiš itd. Na tebi je da napraviš tu tehničku odluku i stojiš iza nje, ni na kome drugom.
Razmišljao sam o CronJobsu. Recimo nekih 15-20min osvježivati podatke. To bi se radilo jednom u 15-20min, a kad korisnik dođe se uzmu samo podaci koji sam obilježio, ne mora se taj veliki query svaki put odrađivat kad se refresha stranica.
To mi se sviđa. Hvala ljudi na pomoći 
P.S. sada čitam za temporary table da se uništavaju nakon što se skripta izvrši. Kako onda mogu iz njih čitat opet podatke.