Leaderboard

Done this for many systems: 100% agree with Barand. I will go one step further and make this an "event" table where the system can insert rows for other events. Off the top of my head other events (in an event_type table or enum) would be a list like this: login logout bad password attempt change password reset password request etc. A simple table like this is common, has and has the benefit (with proper indexing) of allowing for the types of analysis and controls Barand listed. It also allows for mitigating brute force password attempts, as you can use this table to limit the number of login attempts within a given time period for a specific user, and lock the account after a certain number of attempts. Beyond the relationship to the User table (by Id) and a timestamp, you also typically want to store the IP address of the client. If it's mysql, the best way to do this (and natively support both IPv4 and IPv6) is to store the IP as VARBINARY(16) and use the INET6_ATON() and INET6_NTOA() functions to convert the IP when storing and retrieving. Small tables like this, with a clear design scale very well, as MySQL/MariaDB (using the InnoDB engine) is tuned to maximize Select & Insert concurrency. Often people will attempt to use a column or 2 in the user table, which they repeatedly update (ie. "last_login") which reduces concurrency, and is also less valuable than having a full history.