Dove memorizzare il valore medio in db?

risposta aggiornata Ci sono vantaggi e svantaggi nell'aggiungere una nuova tabella e nella sua memorizzazione sulla tabella del ristorante.

Il vantaggio di metterlo direttamente sul tavolo del ristorante è che ottieni tutte le informazioni del tuo ristorante in una sola lettura. Tuttavia, se questa è una riga di grandi dimensioni con molti dati, potresti non voler aggiornarla continuamente.

Metterlo su una tabella "stats" secondaria ha anche il merito, in quanto si tratta essenzialmente di dati transitori. Non perdi nulla facendo cadere il tavolo e rigenerandolo, e gli aggiornamenti sono veloci e leggeri.

Risposta originale prima che fosse chiaro che era necessario memorizzare nella cache la media

Per aumentare le prestazioni mi sembra un'ottimizzazione prematura. Scommetto che in questo caso il guadagno in termini di prestazioni è trascurabile e non vale l'overhead.

Considerare il sovraccarico, nella logica dell'applicazione quando viene aggiunta una recensione, è necessario recuperare tutti gli altri punteggi, mediali e aggiornare la media archiviata.
Devi isolare questa operazione (probabilmente utilizzando una transazione Db), perché non puoi avere due recensioni aggiunte allo stesso tempo.

Devi farlo quando le recensioni vengono aggiunte, rimosse e aggiornate.

Le transazioni Db sono costose e stanno bloccando. Se sei che preoccupato per le prestazioni, ciò danneggerà la tua applicazione molto più di una semplice aggregazione.

Se modifichi manualmente i dati o archivi i dati direttamente, devi aggiornare TUTTI le medie interessate.

Al contrario, il tuo motore Db è stato follemente ottimizzato per eseguire operazioni di aggregazione in tempo reale.

Quindi, per rispondere alla domanda come richiesto. . .
Lo farei solo se hai misurato le prestazioni delle tue applicazioni e conosci ne hai assolutamente bisogno. In tal caso, salvalo sul tavolo del ristorante.

Altrimenti non memorizzare il valore, calcolarlo al volo.

Puoi archiviarlo dove vuoi. Lo memorizzerei nel tavolo del ristorante, ma un altro per le statistiche potrebbe avere un senso: dipende dalla frequenza con cui lo aggiorni e se aggiorni le voci del ristorante spesso o affatto.

Un approccio alternativo sarebbe quello di memorizzare la media nella logica aziendale che recupera e restituisce i dati. La media viene quindi calcolata all'avvio dei servizi e viene aggiornata dinamicamente (ovvero memorizzata nella cache). Non dovresti aggiornare la media nel DB allora - che è spesso più costosa della lettura di molti dati (cioè se aggiorni la media hai trasformato una lettura di righe nella tua tabella in una singola scrittura. ogni volta che viene aggiunta una recensione, farai molte chiamate di aggiornamento relativamente costose)

Non lo memorizzerei affatto.

Quello che vuoi usare qui è un "VISTA". Non un nuovo tavolo. La vista è il risultato di una query, una specie di tabella virtuale.

Ultimo: rifletti sulla tua architettura, la tua soluzione potrebbe non adattarsi bene su un RDBMS

Il tuo problema ha una soluzione su altri RDBMS (postgresql / oracle) senza creare alcuna tabella: a vista materializzata

Aggiornalo con l'attività pianificata con aggiorna la visualizzazione materializzata

Dato che hai MySQL puoi solo simulare una vista materializzata tramite una tabella temporanea. :

• link o
• link (cerca il commento di Rafael Palacios)