Questo, come la maggior parte delle cose, dipende dai modelli di accesso, cioè dal modo in cui verrà utilizzato il sistema. Se l'aggiornamento sarà il collo di bottiglia principale, non dovresti incorrere in un sovraccarico dovuto al mantenimento di un contatore. Se d'altra parte, quando si accede ai dati con il conteggio pronto si risparmia molto tempo o non sarebbe possibile contare ogni volta, quindi si dovrebbe precalucolare.
Come linea guida generale, non aggiungere tabelle, come la tabella dei conteggi separati che proponi, che sono puramente per l'ottimizzazione delle prestazioni prima che tu abbia effettivamente misurato le prestazioni come un problema. Avere una tabella dei conteggi separati rompe la normalizzazione (come qualsiasi tipo di memorizzazione nella cache, dato che i dati sono ora replicati in due punti) e renderà il codice più complicato, quindi non dovrebbe essere fatto solo perché potrebbe essere necessario il conteggio.
(Tutto ciò che ha detto, alcune banche dati supportano materialized views/materialized queries che ti permettono di fare facilmente questo tipo di caching trasparente in background. Coloro materializzata tabelle vengono aggiornate dal database, in modo che il codice di programma non devono preoccuparsi di esso e anche , a seconda della sofisticazione del query Optimizer, può essere utilizzato per ottimizzare una query in modo trasparente)
Aggiornamento:. il No/si domanda voto è un po 'diversa, come lo scopo principale è quello di monitorare solo il conteggio , non necessariamente l'intera informazione (cioè chi ha votato sì). Quindi un'implementazione valida potrebbe essere quella di tenere traccia del numero accumulato di sì e di no. Tuttavia, più informazioni memorizzate (vale a dire chi ha votato sì, e non solo molte) più si può fare con esso se si sceglie di farlo (ad esempio, in Stackoverflow posso sempre rimuovere il mio upvote - qualcosa che non si potrebbe fare se non hai tracciato chi ha votato). Ancora una volta consiglierei di non aggregare prima, in questo caso, perché perderai certe informazioni.
fonte
2011-08-23 11:43:19
Grazie inflagranti, per il voto memorizzo anche singoli record. Ho una tabella di sondaggi e voti. Quindi la mia home page mostra un elenco di sondaggi con testo del sondaggio, conteggio dei partecipanti, conteggio sì e senza conteggio. quindi devo fare un join esterno tra sondaggio e tabella di votazione (supponendo che la nostra tabella di voto aumenterà per un periodo di tempo). Quindi pensi che sia giusto fare outer join con la tabella dei voti? – firefly
@mrbond: per alcune migliaia di sondaggi non vedo alcun problema. È sempre una questione di dimensioni. Inoltre, se necessario, è possibile memorizzare nella cache i singoli sondaggi nell'app-server (quindi non comunicare nemmeno con il server per i 100 sondaggi più richiesti). Ma ancora una volta, a meno che tu non sappia che sarà un problema, non lo aggregerei prematuramente. Se vedi che sta diventando un problema, dovresti essere in grado di reagire in tempo, poiché non si tratta di un cambiamento di progettazione importante (e poiché non lo hai ottimizzato in anticipo, è anche più facile adattarlo). –