1

Let's say I have a database with users, groups and messages at the groups.

And I have 3 views:

Profile view: Where all the details of the user is shown.
Groups view: Where all the groups are shown.
Group view: Where all the messages are shown.

Now whenever the user goes to a view, the view connects to the database to retrieve the data.

  1. Would it be good practice to save the data to the client when it's retrieved, so when the user switches views after the first time it doesn't need to make contact with the database anymore. Which improves load times for the user and also reduces the work for the database.

    And if the data is really big for example the messages, we could only load the last 100.

    Or is it better to retrieve the data every time the user switches views?

  2. If it is good practice to save the data on the client, what would be a good way to check whether the data is updated?

8
  • 1. You're describing a "cache." May 6 '17 at 21:32
  • 2. Cache invalidation. May 6 '17 at 21:32
  • Oh really. Haha thank you I didn't know.
    – Soundwave
    May 6 '17 at 21:39
  • "load only the last 100" is called "paging." May 6 '17 at 21:45
  • BTW, cache invalidation is a second worst problem of programming. Only naming is harder.
    – Basilevs
    May 7 '17 at 15:53
0

If you should save a copy of the data on the client side, effectively leading to a cache, depends on a lot of factors, some of which are the following:

  • Does your business case allow you to show anything but the newest data? How bad is it if your users see invalid/old data?
  • How much data are you talking about? What is the size, count and type of your messages and other data?
  • Is it a requirement to show the last known values when the database is not available? What should happen if the client is offline or you do a maintenance of your database and disallow connections from clients?
  • Is your data hard to fetch? Do you need to join hundreds of tables or calculate lot of things on each request?
  • How powerful is your database? how many clients do you have on average and at peak load? How many requests do they produce?
  • What type and speed of network connection do clients have to your database? How much does the latency impact you?
  • What are your requirements on performance? How long may it take to load and show all the data?
  • Do you have evidence that not caching the data is too slow?

If you are unsure about these things, you probably don't need it right now. You add complexity if you add caching to your clients and a lot more complexity to invalidate it at appropriate times. Cache invalidation is hard to get right. It is a form of premature optimization and you may not need it, so it is probably better to keep it simple now but adhere to good coding practices to simplify future changes.

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.