P.S. unica pecca in questo ragionamento è che quando cancello un topic devo andare a ricercarmi l'ultimo messaggio per quella determinata categoria e aggiornarlo...
P.S. unica pecca in questo ragionamento è che quando cancello un topic devo andare a ricercarmi l'ultimo messaggio per quella determinata categoria e aggiornarlo...
E quale sarebbe la "pecca"?Originariamente inviato da markzzz
P.S. unica pecca in questo ragionamento è che quando cancello un topic devo andare a ricercarmi l'ultimo messaggio per quella determinata categoria e aggiornarlo...
Come sopra
1) lato applicazione => aggiorni
2) lato db => trigger => aggiorni
---
Riguardo all'ottimizzazione di "prendi ultimo messaggio" ci si potrebbe lavorare sopra, ma direi di non complicarti la vita con le "finezze" prima di aver levato "il grosso"
---
Per utf8 e myisam... uomo avvisato...
il tuo approccio NON funzionerà, o meglio NON scalerà.
Per un mini-db va ancora bene, poi scatterà l'effetto lock-lock-lock=lento-lento-lento
La pecca è che appunto se cancello il topic (che magari contiene l'ultimo messaggio) devo andare a ricercarmi nei topic quale è in quel momento l'ultimo messaggio e aggiornare nuovamente la tabella; si, una query in più, nulla di che
versione breve: legge di Amdahl.Originariamente inviato da markzzz
La pecca è che appunto se cancello il topic (che magari contiene l'ultimo messaggio) devo andare a ricercarmi nei topic quale è in quel momento l'ultimo messaggio e aggiornare nuovamente la tabella; si, una query in più, nulla di che
Ultimo consiglio : per gestire i topic che un utente deve ancora guardare? Io ho forum_visits, con topic/utente.
Solo che se volessi vedere dalla lista categoria quali sono le categorie che hanno dei topic che devo ancora visitare anche lì dovrei fare un super join.
Devo migliorare anche quella parte, se magari hai consigli
EDIT : io pensavo a mettere un forum visits con (category, topic, user) e fare un singolo LEFT OUTER JOIN con questa tabella e forum_categories, mettendo un SUM(CASE WHEN r.user IS NULL THEN 1 ELSE 0 END) per vedere se ci son topic da vedere...
non è che abbia capito un granchè di come vuoi fare, nè perchè vuoi usare a tutti i costi un campo che può essere null (come detto non è cosa buona e giusta), nè che c'entra sommarli (inteso come ricerca).Originariamente inviato da markzzz
Ultimo consiglio : per gestire i topic che un utente deve ancora guardare? Io ho forum_visits, con topic/utente.
Solo che se volessi vedere dalla lista categoria quali sono le categorie che hanno dei topic che devo ancora visitare anche lì dovrei fare un super join.
Devo migliorare anche quella parte, se magari hai consigli
EDIT : io pensavo a mettere un forum visits con (category, topic, user) e fare un singolo LEFT OUTER JOIN con questa tabella e forum_categories, mettendo un SUM(CASE WHEN r.user IS NULL THEN 1 ELSE 0 END) per vedere se ci son topic da vedere...
nè, soprattutto, se ti può interessare sapere a quali tra millemila topic un utente NON ha letto.
Se mi iscrivessi qui, ad esempio, che fai? mi mostri un milione di post che non ho letto?
bisogna che ragioni un pochino sulla logica che vuoi dare, a mio parere
ma pensavo appunto una cosa del tipo "immagine rossa" se non ho letto il topic (quindi, quando mi iscrivo, tutti rossi).Originariamente inviato da franzauker
Man mano che li vedo, verdi. Ogni volta che visito un topic aggiungo un flag sul database (del tipo category, topic, mio_user) e quando uno aggiunge una risposta, cancello tutti i flag corrispondente a quel topic.
quel SUM deriva dal fatto che, se faccio left outer join e trova NULL (derivato dal left outer join, non ho campi null), significa che un utente non ha visitato quel topic, e incrementa di 1.
Se il conteggio è maggiore di 0 significa che almeno un topic non è stato visitato. Se è 0 tutti visitati.
Te ad esempio come fai? Così giusto per farmi una idea
P.S. comunque grazie per il tuo tempo
Semplice, non faccioOriginariamente inviato da markzzz
ma pensavo appunto una cosa del tipo "immagine rossa" se non ho letto il topic (quindi, quando mi iscrivo, tutti rossi).
...
Te ad esempio come fai?
aggiornare una cosa del genere significa centinaia di migliaia di query al giorno "inutili" (nel senso "non indispensabili")
Mi sembra estremamente onerosa, come funzione.
Ossia vuoi tenere traccia, per ogni post ed ogni utente, di un flag nel quale lo metti "letto".
Se hai un milione di post, e mezzo milione di utenti, ti servono cinquecento MILIARDI di byte di flag (nel caso in cui gli utenti hanno letto tutti i post, tranne i nuovissimi).
Mmmhhhh... mi pare un pochino dispendioso...
---
Se invece ragioni sul thread allora la cosa è meno ovvia, perchè uno potrebbe aver letto una pagina (magari la pagina 3), e non la pagina 4 del thread.
Quindi per te "letto" è relativo ad un thread, oppure ad un post?
Maieuticamente vediamo dove si può arrivare, portando alle conseguenze il discorso...
per me un thread è letto, non un post
Nel senso, questa discussione conterrebbe come un singolo thread
Giusto per curiosità, e quando diventa "letto" un thread?Originariamente inviato da markzzz
per me un thread è letto, non un post
Nel senso, questa discussione conterrebbe come un singolo thread
Quando l'utente accede almeno ad una pagina?
Accede a tutte?
Accede all'ultima?
Permessi di invio
Rispondi quotando