Search code examples
databasedatabase-designuser-inputn-tier-architecture

Strategy for tracking user recent activity

Our customer would like to know who is online and currently using the custom application we wrote for them. I discussed it with them and this does not need to be exact, more of a guestimate will work.

So my thought is a 15 minute time interval to determine user activity. Some ideas I have for doing this are as follows:

  1. Stamp their user record with a date and time of their last activity every time they do something that hits the database, or requests a web page ... this though could be quite database intensive.

  2. Send out a "who is online request" from our software, looking for responses, this could be done at a scheduled interval, and then stamp the user record with the current date and time for each response I received.

What are your thoughts? And how would you handle this situation?

Clarification

I would like to use the same architecture for both Windows or the Web if possible. I have a single business logic layer that multiple user interfaces interact with, could be Windows or the Web.

By Windows I would mean client-server.

Clarification

I am using an n-tier architecture so my business objects handle all the interaction with the presentation layer. That presentation layer could be feeding a client-server Windows application, Web application, Web Service and so on.

It is not a high traffic application, as it was developed for a customer of ours, maybe 100 users at most.

Solution

  • Our solution is to maintain a "Transaction" table (which follows what was done), in addition to our "Session" table (which follows who was here). UPDATE, INSERT and DELETE instructions are all managed through a "Transaction" object and each of these SQL instruction is stored in the "Transaction" table once it has been successfully executed on the database (depending on tables updated: we have the possibility to specifically follow some tables and ignore others). This "Transaction" table has other fields such as transactiontType (I for INSERT, D for DELETE, U for UPDATE), transactionDateTime, etc, and a foreign key "sessionId", telling us finally who sent the instruction. It is even possible, through some code, to identify who did what and when (Gus created the record on monday, Tim changed the Unit Price on tuesday, Liz added an extra discount on thursday, etc).

    Pros for this solution are:

    1. you're able to tell "what who and when", and to show it to your users! (you'll need some code to analyse SQL statements)
    2. if your data is replicated, and replication fails, you can rebuild your database through this table

    Cons are

    1. 100 000 data updates per month mean 100 000 records in Tbl_Transaction
    2. Finally, this table tends to be 99% of your database volume

    Our choice: all records older than 90 days are automatically deleted every morning