Mislim da ti je mnogo bolje koristiti obican sql upit. Procedure jesu brze, ali ako ne ocekujes milion poseta dnevno, ne vredi tog masiranja.

Pri kreiranju tabela možda ćeš se zapitati InnoDB ili MyISAM, ukratko InnoDB je ako imaš dosta INSERT, UPDATE operacija, dok je dok je MyISAM bolji za SELECT. Sada ti vidi šta ti je potrebnije, naravno ove razlike se iskažu tek pod malo većim opterećenjem ali ne škodi u startu biti pripremljen ;)

Ne pratim brojkama ali noviji razvoj u InnoDB bi trebalo da ovu razliku ispegla. MyISAM radi zaključavanje cele tabele i ne podržava strane ključeve.

U svom iskustvu pogled sam pravio jedino kada ima smisla da takva reprezentacija podataka postoji. Izbegavam podupite i koristim spajanja normalizovanih tabela. Po osećaju ponegde kada su čitanja česta, a promene retke ostavim i neki atribut viška (na primer stanje računa da ne bih stalno premotavao tabelu transakcija).

@mitke013: imaš li neke brojke za „procedure jesu brze“?

Generalno imam vise SELECT upita ali ja uvek koristim InnoDB, evo jednog posta gde se dobro vidi da je InnoDB puno bilji od MyIsam.
http://www.mysqlperformanceblo...m-vs-falcon-benchmarks-part-1/
Ali ono sto mene interesuje je da li je bolje da ako imam, na primer, vise tabela koje treba da joinujem, da li je bolje da u bazi napravim pogled i onda uradim select iz tog pogleda, ili da direktno iz php-a u query upit stavim sql kod.
Na primer:
Da li je bolje da u bazi napravim jedan pogled

I onda da samo uradim:

Ili je bolje da direktno iz php-a stavim:

Ili je mozda bolje da uradim vise select upita prema bazi.

Mislim da query cache radi svoj posao u oba slučaja.

Pogled kao TEMPTABLE ne omogućava update/delete. Može biti nezgodno u aplikativnoj logici objasniti CRUD operacije nad pogledom ako isti nije dobro definisan po dekomponovanim domenima.

Ja sam radio jednu aplikaciju gde je baza bila Oracle, i ceo development aplikacije se razvijao na sledeci nacin:
Developeri baze su za svaki UPDATE, DELETE, INSERT upit pravili procedure, a svaki SELECT upit se vrsio iz pogleda koje su oni pravili.
Nije bilo dozvoljena manipulacija podataka direktno iz tabela.

E sada ja radim slicnu aplikaciju ali je baza mysql i interesuje me da li da se drzim iste logike ili ne?
Baza je mala nema 5-6 tabela ali glavna tabela i history tabela(u njoj se cuvaju sve akcije korisnika aplikacije) ce imati jako mnogo zapisa (vise od milion).
I pre nego pocnem da radim moram da osmislim nacin na koji cu ubrazati rad aplikacije. Jer prva verzija te aplikacije postoji i u njoj sam koristio poglede(jedan primer pogleda vtracker ste videli) i gnerealno aplikacija radi jako sporo.
query_cache nije bio ukljucen.

Prouči plan izvršavanja upita.

Ne, samo informacije iz druge ruke. Doduse, izvor mi nije narocito pouzdan, ali on tvrdi da je testiranjem dosao do toga da je procedura oko 2 puta brza nego obican SQL upit.

Znaci definitivno procedure i i pogledi?

^ Ne verujem u to dok ne testiram...

Evo ja sam nasao neke clanke:

http://www.mysqlperformanceblo...w-as-performance-troublemaker/

http://www.mysqlperformanceblo...es-problems-and-use-practices/