Queuing update requests for a giant update?

I have a site, and when the user does an action I wish to add that to a count of how many actions the person has ever done. Naturally I'd say "update the user table each time!" but I don't feel as if that's a good solution, and I'm interested in seeing if there is a way to do this.

Basically the user would log in and start using actions, and every time they make an action I would do [whatever] and then at th开发者_StackOverflowe end of the day, I take all [whatever]s and make the query, saving resources on each action. Were the site to grow to 1,000 users, those little queries would start adding up! There is only one type of "action", for the sake of this question just assume each page load would be an action.

---

if its a single session, store (queue) "all the updates" in a session / global variable. Update at the end of the session.

if its a multiple-session system, I would suggest doing the above and update the table at the end of each session.

:(upwards of few hundred kbs, this is not a good idea):

You would want to make a shortcode endcoing /decoding library to store it into the sessions vars. If we are talking about huge data. For example, if you have a drag and drop system, the intermediate states could be key<>val pair structures. eg: LOC_A=WIDGET_1 ; LOC_B=WIDGET_88 .. so on and so forth..

is this making sense?

---

Don't discount keeping an action event table. Unless you have very high user action rates it may easily be reasonable to query and count action events rather than accumulating totals somewhere. An index can provide single-block read access to several hundred or thousand events with a reasonable design. Developers often can be intimidated by table sizes for stuff like this that are actually quite reasonable. IME a table size of several GB is not a problem for MYSQL as long as the table is write-only.

As usual, testing several options is the best idea, and expect to be surprised.