I am the lead developer on a commercial Windows app (c#). A new requirement is to track customers who abuse the license.
For example: Let’s say a customer purchases a 10 user license agreement, i.e. 10 simultaneous users at any given time.
I need to be able to report, looking back at history, all the times that customer had more than 10 users logged in at the same time.
I already have a User table with columns: userid (primary key), pw, lastLogin, lastLogout.
I was thinking about creating a a new ‘logging’ table in which a new row is added each time a user logs out…columns might include:
LogId, UserId, LoginDateTime, LogoutDateTime
…and then I would have a history of every time a user logs in/out of the app…
but I’m not sure if this table design will lend to efficient calculations for reporting…whether I use SQL or c# to perform the calculations does not matter to me, as long as it is reasonably fast…
Hoping someone might have a good idea about how to better design this table so that I can quickly calculate any/all points in time when the customer exceeded the license limit.
Note: I do not want to block the 11t, 12th etc. user from using the app…the requirement is to display a warning message to the user but to allow him to continue working…
Think about starting and ending sessions as events that need to be recorded. You create a single table to record these events.
So, a session that starts and ends will have two entries in the table – one for the session start and one for the session end. You only ever add records to the table, never modifying previous records. The table can keep track of the number of open sessions very simply now by adding a ‘session count’ field to the record that is incremented from the previous record’s session count value when a session start event occurs and decremented when a session end event occurs.
The ‘session count’ column now gives us a piece-wise continuous function over time of the number of concurrent sessions.
Example data:
Things to worry about:
EDIT: please note that where I put ‘your session data here’, I really meant ‘your session event data here’. Information such as a time stamp would go in here. Another table should be used to track session information common to both events, such as the identity of the user that owns the session (use the same SessionId key for both tables).