post nuovi/letti

[FinalFantasy]

dovrei fare una specie di forum e vorrei capire come si gestisce al meglio la visualizzazione di post letti o di nuovi post...qualcuno sa darmi, questa volta, una risposta completa ed efficace?

[luke83]

nel record del post un bit alto se già letto.. i nuovi fai un confronto data attuale con data del post e selezioni a dovere..

[FinalFantasy]

Originariamente inviato da luke83
nel record del post un bit alto se già letto..

non credo ke sia la soluzione migliore: ho 100 utenti, devo mettere 100 bit? 1000 utenti, 1000 bit?

[luke83]

prima di tutto il bit ava al post e nn all'utente.. devi fare una tabella di cross di questo tipo:

uid|pid
 1 | 1
 2 | 4

quanto sopra dice che l'utente uno ha letto il post uno e l'utente 2 ha letto il 4...

[FinalFantasy]

Originariamente inviato da luke83
prima di tutto il bit ava al post e nn all'utente.. devi fare una tabella di cross di questo tipo:

uid|pid
 1 | 1
 2 | 4

quanto sopra dice che l'utente uno ha letto il post uno e l'utente 2 ha letto il 4...

ancke un mio amico mi ha detto ciò...e nn è una soluzione ottimale...metti ke ci sn 100 post e 100 utenti...tutti gli utenti leggono tutti i post, ci sarà una tabellona di 10000 righe...

[luke83]

mah.. dico una cosa che se il mio prof di basi legge mi toglie il trenta dal libretto e mi ci mette un 3...

table user

id|username|letti
 1| luke83 |1,2,3

e questo dice che ho letto i post 1,2,3 ma nn mi piace proprio io mi terrei i 10000 rec che nn occuperanno neanke un mega tanto so numeretti e basta.. l'overhead rispetto a questa soluzione pezzotta nn è molto e quella è la maniera corretta nn questa ne perdi di prestazioni invece che di memoria...

fai te..

[FinalFantasy]

preferisco la seconda...alla fine devo fare un explode è un controllo usando in_array

potrei perdere qualke microsec, anzike di centinaia di preziosi Kb nel db...sprecare 500/800 Kb x ciò sembrerà poco, ma se vedi tutto il sito, mi darai ragione...

[Gianni_T]

e chi ti dice che risparimerai spazio? In un caso usi un varchar (stringhe) e dovrai memorizzare anche la virgola. Nel secondo caso un intero. Fai 2 conti: una stringa tipo "12,34,123" necessita di almeno di 9 byte più un byte per il varchar mentre per 3 numeri interi te la cavi con 6 byte.
E l'aumento è esponenziale. Immagina la stringa "1234,2345,3456,4567" ...

E poi c'è il costo dell'explode, anche questo in crescita

[luke83]

infatti...

Originariamente inviato da luke83
l'overhead rispetto a questa soluzione pezzotta nn è molto e quella è la maniera corretta

[FinalFantasy]

mah...lo stesso overhead ke hai x esplodere e fare un in_array è lo stesso ke hai x fare la query e un ciclo while per prendere i dati...nn credo ke poi cambi molto, nn credi?