-1

I have a ratings web app where I want to output the average of all the ratings. How I'm currently doing it is recalculating the average every time a new review is posted and storing that in a database table, and every time someone lands on that page, I retrieve the value from that table. Is there a better way of doing this? Can I store it in a global hash table instead? I've heard that it is bad practice, but can someone shed some light on it?

Edit: Just to be clear, I'm not looking for anyone to code anything for me, but as someone who's building his own website I thought that this would be the best place for me to get some help on whether or not the method I'm currently using is the best way for me to proceed.

  • 2
    "Is there a better way of doing this?" What's your goal? Did you measure a performance problem with your current mode of operation? There are alternatives to calculating the average every time, but it's unclear why you want to do this. In general, unless you measured that this piece of code was problematic, I wouldn't change a thing. If you did measure a performance issue, then the general solutions apply: keep the value in memory (caching), create a materialized view in database, etc. – Vincent Savard Dec 17 '18 at 11:37
  • 1
    Caching the average rating seems to be a good idea in general in case you don't retrieve all reviews from the database anyway. I would then store the average rating together with all the other information about the product in the database. – Jan Linxweiler Dec 17 '18 at 11:38
1

It is usually avoided to keep any state within the process so that the process can be restarted or run in parallel, without any data loss. E.g. when your web app has two parallel processes that serve requests, and one process changes the average, this change will not be visible in the other process.

It is fine to keep cached data within the process, as long as you are aware under which conditions this data may be out of date and would have to be invalidated. For example, if the exact average is not very important, you might be fine if it is 10 minutes out of date.

Aside from caches that may be out of date, any state should be kept external. This would usually be the primary database, but you might combine this with an external key-value store, e.g. Redis or Memcached. You still have to keep this cache up to date, but at least it is shared by all processes.

A lot here depends on what scale you will be operating on. Averaging a few thousand reviews is not a big deal, and you probably shouldn't spend any time optimizing this. Similarly, if you are sure that you will never scale beyond a single process of your web app, keeping temporary caches within that process might be tolerable. Note that even low-end architectures (such as LAMP) already imply multiple parallel processes. Beyond that, the recommendations of the Twelve-Factor App (https://12factor.net/) become relevant, in particular the emphasis on a share-nothing architecture.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.