4

I have a Quiz Website build using Codeigniter and MySQL.

Quiz evaluated using these two methods.

  1. Sending request each time user submit the Answer.(10 Database Queries for 10 Question).
  2. Sending request at end of Quiz. (That would require a Query and a lot of Calculation for searching the Answer from the Resulted array.)

I'm thinking to stored the temporary(until quiz is not submitted) Data in Session.

note: Stored data is not a directly fetched result from database but it is a processed Array using PHP before sending it to View

by doing so i can save 10 Queries in first case.
In second Case it saves me a db query and time to process the Database result.

It was the best solution i got until i read these few Questions on Stackoverflow

Question 1 Question 2 Question 3

Basic Idea that got from the above Questions is to Use database Query (because of KISS rule, might return stale data).

yes it will be eating up lot of disk space but i think at the same it is increasing performance of website.

So My Question is that:
1. Which is better Idea "to Store Calculated Result" or "Re Query then Calculate the Result"?
2. How the Session will impact the Performance of the Website?

Community
  • 1
  • 1
sanjay kushwah
  • 437
  • 7
  • 21

1 Answers1

7

What is "better" really depends on how you want the site to perform. Do you want partially finished quiz data to be forgotten if the user session is lost for any reason?

Generally speaking, don't concern yourself with "how many queries it's going to take", at least not for this specific problem (particularly since you're probably storing session-related data in the DB anyway), concern yourself with "what makes the most sense."

You're going round trip to the DB at least once (and probably a few times) with each page request anyway, one additional query to insert/update a row that is properly indexed isn't going to be a problem. Losing the results of someone's quiz when their browser craps out or they lose their session in some way (your fault or theirs) is probably something you want to be more interested in avoiding.

In short: You haven't provided a very compelling reason NOT to store user answers in the DB, and there are probably dozens (if not more) good reasons to not rely on the user's session for this.

Edited to add: Remember, the database's job is very simple: To store data. Use it for what it's intended for. ;)

StudyOfCrying
  • 530
  • 3
  • 9
  • Thanks @StudyOfCrying, but there are few thousand rows both in Question table and Option table...so if one is accessing the session rather than querying the database will be faster. what is ur opinion? – sanjay kushwah Nov 17 '12 at 19:46
  • 2
    thousands of rows are nothing if you have optimised your query. `session` can't replace db queries in your case. that's the bottom line. – itachi Nov 17 '12 at 19:48
  • 2
    Do not worry about faster until you have to worry about it--a few thousand rows is nothing if you have a solid schema, good queries, and the correct indexes. There are so many different ways of doing this that could make one or the other solution faster, and many paths to optimization if speed is a problem. Design it *correctly* and don't be worried about milliseconds. – Francis Avila Nov 17 '12 at 19:51
  • 1
    itachi has the right of it, thousands of rows is absolutely insignificant. I'd give the same advice if we were talking about millions of rows. If you are having performance issues storing user question responses with such a tiny dataset I suspect one of two things: Your model is poorly designed or your tables aren't properly indexed. Are you not storing session data in the DB as well? If you're relying on content-related session data storage in the user's browser you're doing it wrong. A session is (primarily) used to identify the user and tie them to internal data, nothing more. – StudyOfCrying Nov 17 '12 at 19:52
  • Thanks to all..this really helps me a lot..you guys really changed my opinion about the session :) thanks a lot guys. – sanjay kushwah Nov 17 '12 at 19:57