Rails - Caching somme totale des recettes dans une application de budgétisation - meilleure pratique

Question

Contexte: application de suivi de budget qui aura beaucoup de recettes appartenant directement à un utilisateur. Un des nombreux calculs que je devrai garder est un total cumulé de tous les reçus entrés depuis le jour 1. Avec le temps et l'augmentation des recettes, cela prendra plus de temps à calculer et peut-être devenir un goulot d'étranglement. Et cela sera appelé fréquemment - chaque fois qu'un utilisateur ajoute un nouveau reçu, édite un ancien, etc.

Donc je me demande comment éviter cette somme constante. Peut-être que je devrais en quelque sorte sectionner les reçus de clôture dans des dossiers mensuels, chaque dossier gardant une trace de son sous-total. Donc, si vous ajoutez un nouveau reçu à un mois, seule la somme est calculée pour ces reçus. Est-ce la bonne approche et comment devrait-elle être mise en œuvre? Devrais-je créer un modèle de mois ici?

Je ne suis pas une grande conception db et j'espérais que quelqu'un pourrait peut-être commenter cette approche ou offrir un moyen plus propre.

Answer 1

Jetez un coup d'œil à counter_cache dans l'enregistrement actif. Cela ressemble à un exemple classique.

Sur le modèle User, vous allez ajouter une colonne "receipts_count".

add_column :users, :receipts_count, :integer, :default => 0, :null => false 

Et sur le modèle recettes, vous allez ajouter

belongs_to :user, :counter_cache => true 

Vous aurez envie de regarder aussi dans la façon de définir ce nombre au départ. Vous pouvez le faire avec une tâche rake ou dans la migration. Cela a quelques pièges, comme vous le verrez. Les caches de compteur sont en lecture seule et pour les mettre à jour dans une migration, vous devez définir la valeur et la commande ActiveRecord :: Base.connection.execute ("...")

Il y a beaucoup de discussions à ce sujet sur le web, les bulletins, etc., et il y a moyen d'ajouter un compteur personnalisé si vous voulez, vous voudrez en lire plus que je ne peux ajouter ici.