Va bene strutturare una tabella non normale nel database relazionale per ottenere una query veloce?

Devi registrare le informazioni derivabili solo quando assolutamente necessario, dopo che è stato osservato che una query o una vista sulla tabella Tagged non è pratica.

Tuttavia, una volta presa la decisione di memorizzare queste informazioni, la registrazione delle informazioni derivabili va bene, a condizione di mantenere la coerenza. Considera l'implementazione come trigger sulla tabella Tagged per garantire coerenza a livello di database, in modo che le modifiche dirette al database (ad esempio, da parte di un DBA) non possano rompere i tuoi dati.

A proposito, la tua entità associativa dovrebbe essere solo una relazione ternaria. Le entità associative nel modello ER sono richieste solo quando una relazione deve essere oggetto di un'altra relazione.

Non consiglierei di farlo.

Complifica il database con ciò che è essenzialmente un valore memorizzato nella cache o un rapporto.

Un valore memorizzato nella cache può essere mantenuto al di fuori del database

Un report dovrebbe essere fatto su un server di report.

Vorrei specialmente non raccomandare l'uso di trigger per mantenere aggiornato il valore. Questo potrebbe rallentare davvero il tuo db.

La tua applicazione potrebbe utilizzare un numero qualsiasi di aggregati e calcoli diversi, aggiungerai ognuno come una colonna in più su un tavolo?

Eseguire la query aggregata e memorizzare nella cache il risultato nell'applicazione (invalidando quando richiesto) oppure eseguire un report ogni giorno e utilizzarlo.

Nel complesso aggiungere la colonna in più è una soluzione molto incentrata sul database. Se hai un livello applicazione o API sopra il database avrai a disposizione più opzioni per evitare questo problema.

Ad esempio, se recupero sempre una traccia e i relativi tag insieme per popolare un oggetto aggregato, non è necessario calcolare il numero di tag nel database.

Se voglio mostrare il numero di tag al giorno, a settimana, ecc., una sola colonna della tabella traccia non mi aiuta più. Posso interrogare Track + i tag di oggi dal DB di transazione e la frequenza Tag nel tempo per quella traccia dal cubo di segnalazione che sarà ottimizzato per quel tipo di query sui dati storici.

Anche se desidero un on demand fino al secondo report delle tracce Tagged più frequentemente in ogni momento, per il quale sarebbe utile una singola colonna aggiornata. Non aggiungerei ancora la colonna. Invece avrei l'applicazione sollevare un evento quando è stato aggiunto un tag e gestirlo in una soluzione completamente separata, possibilmente statsd o un cubo di reporting a cui scriverei direttamente.