Performance des vues par rapport aux tables pour les données temporelles changeantes

Question

J'ai un tableau pour les articles de presse, contenant entre autres l'auteur, l'heure affichée et le nombre de mots pour chaque article. La table est plutôt grande, contenant plus d'un million d'entrées et grandissant avec un nombre de 10.000 entrées chaque jour. Sur la base de ces données, une analyse statistique est effectuée afin de déterminer le nombre total de mots publiés par un auteur spécifique dans une fenêtre temporelle spécifique (un pour chaque heure de chaque jour, un pour chaque jour, un pour chaque jour). chaque mois) combiné avec une moyenne pour une période de temps. Voici deux exemples:

• Auteur A publié 3298 mots sur 2011-11-04 et avant 943,2 mots en moyenne pour chaque jour deux mois (de 2011-09-04 à 2011-11-03)
• Auteur B a publié 435 mots sur 2012-01-21 13 heures-14 heures et une moyenne de 163.94 mots chaque jour 13 heures-14 heures dans les 30 jours avant

la pratique actuelle est de commencer un script à la fin de chaque cron-job, qui calcule le nombre et les moyennes et le stocke dans un tableau séparé pour chaque fenêtre temporelle (c.-à-d. un pour chaque fenêtre horaire, un pour chaque jour, un pour chaque h mensuel etc ...).

Le calcul des sommes et des moyennes peut facilement être fait en SQL, donc je pense que Views pourrait être une solution plus élégante à cela, mais je ne connais pas les implications sur les performances.

Views est-il une solution appropriée au problème décrit ci-dessus?

Answer 1

Je pense que vous pouvez utiliser matérialiser les vues pour cela. Ce n'est pas vraiment implémenté dans MySQL, mais vous pouvez l'implémenter avec des tables. Look at

Answer 2

Les vues ne seront pas équivalentes à votre dénormalisation. Si vous déplacez des nombres agrégés ailleurs, cela a un certain coût, que vous payez - afin de garder les données correctes, et un certain bénéfice, qui est beaucoup moins de données à consulter lors de l'interrogation. Une vue vous évitera d'avoir à réfléchir trop à propos de la requête chaque fois que vous l'exécuterez, mais elle devra toujours examiner la plus grande quantité de données dans les tables d'origine.

même si je ne suis pas fan de la dénormalisation, puisque vous l'avez déjà fait, je pense que la vue n'aidera pas.