[MySQL] Registrazione ad un post e visualizzazione

[neo87cs]

Ciao a tutti,
cercherò di essere quanto più chiaro possibile per farvi capire cosa intendo... allora, immaginatevi una sorta di forum (più o meno), io ho le tabelle USERS, POSTS, COMMENTS di questo tipo:

USERS: username, password, dati vari
POSTS: id, autore, testo, dati vari sul post
COMMENTS: id, posts (chiave esterna), user (chiave esterna), data di creazione, testo del commento

ora... io dovrei gestire due cosee fondamentali: la funzione "mi piace" e "segui il post"... La prima funzione è abbastanza intuibile (tutti usiamo fb) mentre la seconda serve a visualizzare le ultime novità sui post a cui un utente di è iscritto.

La prima l'ho gestita semplicemente aggiungendo due campi "piace" e "npiace", piace contiene la lista degli utenti memorizzata in stringa e npiace contiene il numero di utenti che ha cliccato mi piace; so che non è il max, ma mi è sembrata la modalità più efficiente per memorizzarli in quanto non si offre all'utente la possibilità di vedere i post "piaciuti"... La seconda però non so davvero come memorizzarla... vorrei trovare un modo che mi permetta di andare a trovare le ultime novità riguardanti i post seguiti da un utente senza girarmi intermanete la tabella comments O.O

[webking2003]

Allora io ti proporrei questa soluzione per i due quesiti
Per quanto riguarda il "Mi piace" creerei una tabella
nomeTabella : MiPiace
ID_MiPiace (chiave primaria e autoincrement)
ID_Utente (ID del'utente che ha cliccato il "miPiace)(Chiave UNIQUE)
ID_Post (Post piaciuto)(Chiave UNIQUE)
timestamp_mipiace

Vedi bene che io ti ho proposto di inserire entrambe le due chiavi unique in quanto un utente può cliccare 1 sola volta il "mi piace" altrimenti se il record esiste lo puoi cancellare (perchè se hai cliccato il 'mi piace' ti uscirà 'non mi piace' nel caso tu vuoi permettergli di eliminare la scelta)


Per la seconda soluzione puoi optare per una cosa molto simile alla precedente
nomeTabella : seguiPost
ID_seguiPost (chiave primaria e autoincrement)
ID_Utente_FROM
ID_Utente_TO
timestamp_seguiPost

Praticamente con una query puoi estrarti la lista di tutte le persone di cui quell'utente sta seguendo i post e quindi ricavarti tutti i suoi articoli ecc...

Spero di essere stato abbastanza chiaro.
La mia voleva essere più una spiegazione concettuale che tecnica perchè quella poi va effettivamente applicata al singolo caso.

[neo87cs]

il dubbio mio, in fase di caricamento di un post e delle varie news delle home non è un po pesantuccio questo sistema??? alla fine io potrei contenere (parlo dei mi piace) i nomi in una stringa e poi linkarli ad una pagina che raggiunge una presentazione del profilo del tipo nomesito.com/nomeutente... non verrebbe più leggero??? I vari controlli ovviamente li metto nelle routine del sito :P

[webking2003]

Non è che è pesantuccio, la normalizzazione secondo il mio parere va proprio improntata in questa maniera...


Comunque veniamo a noi.. Tu i Post te li devi recuperare lo stesso per mostrarli quindi non ti resta altro che fare una join e vedere se lui ha cliccato il "mi piace" o meno e quindi mostrare di conseguenza il tasto giusto portandoti anche il conteggio...

Non ci vedo nulla di strano, tu vorresti mettere in una stringa tutti i nomi degli utenti che hanno cliccato il "mi piace" ?? ma scusa e come te li recuperi?? Non serve sempre una query? quindi se devi farla la fai come si deve, con una struttura che ti permette poi in futuro di fare quello che vuoi,ampliare e gestire più cose,fare statistiche ecc!

Poi la mia è una semplice opinione..

[neo87cs]

in effetti su questo hai ragione... in futuro permette eventuali estensioni... la gestione della stringa avviene affrontando qualcosa del tipo "user-user-user-user" con controlli di integrità gestiti dalla pagina... in questo modo semplicemente (a mio avviso) si aumenta l'efficienza di non dover chiamare in causa più tabelle e, quindi, non appesandendo troppo il lavoro del db :P