zamislimo sljedece.
Na sistemu (web sajtu) postoji objekat (kao recimo slika na facebook-u) koji clanovi zajednice mogu da “lajkuju”. Zanima me koja bi po vasem misljnju bila najbolja realizacija baze za ovakvo nesto.
Prvo, imamo tabele users i objects sa naravno id-evima.
Da li doticnu tabelu likes kreirati u formatu:
a) id | _object_id | _user_id
gdje se za svaki “lajk” upise jedan red sa pomenutim podacima
b) id | _object_id | _users_id
gdje bi se cuvao string tipa “85.59.89.95.11.586.269” za _users_id a brojevi bi svakako bili id-evi korisnika.
Ovo je cisto pitanje performansi i optimizacije, jer zamislimo da 3000 korisnika “lajkuje” po 50 (od recimo 1000) objekata to bi znacilo 150 000 redova u bazi.
Ima li neko iskustva sa ovim, posebno neko ko je testirao ovako nesto?
Kakva su vasa misljenja?
Po meni, nema tu puno razmišljanja, opcija a) je jedino rješenje, sve ostalo je pimplanje.
Za tablicu pod a) treba vidjeti da li je potreban id sloga jer u toj tablici neće biti update-a pa time id gubi smisao.
Da u slucaju a) bi ID bio suvisan. Spaseno nekoliko bita po unosu.
Svakako i ja racunam na opciju a) svakako je dobro porazgovarati na ovu temu, to je cesta pojava na novim portalima.
Vjerujem da svako koristi nesto slicno na sistemima koje razvija (naravno ako su donekle zabavnog karaktera).
nesvaćam zašto će ti user_id ako nisi mislio postavljati favorite možeš i to izbaciti
da mene pitas ja bi jos ubacio id_frends,tako bi znao koje stvari su ti frendovi lajkali
Mislim da se nismo najbolje razumjeli. Potrebno mi je da znam koji user je “lajkovao” koji objekat.
Da se radi samo o broju lajkova, imao bih kolonu like u tabelu object
Da upravo zbog relacijskog odnosa sam i razmisljao o ovome, svakako sam i sam uvidio to rjesenje kao najbolje, ali rekoh mozda ima neka druga opcija koja mi u tom trenutku nije padala na pamet.