The only time it’s truly beneficial to have a unique id is if it’s referenced in another table, and that’s more just to eliminate the need to carry a multi-field FK on another table. So while I would probably put one on for the programming reasons you mentioned, it’s not required from a database perspective.
In this case, user_id and logged in WOULD create a unique key.
i agree, but i think what you meant to say is “surrogate key” – an artificial number, often an auto_increment or identity column, that acts as PK in place of other candidate keys (or when no candidate key exists, but in those cases i’d always go back to the ER design and redo it)
an actual unique ID is descriptive of every PK, and this includes composite PKs if you stretch the definition of “ID”
(It is theoretically possible for 2 computers to simultaneously, or at least simultaneously to the degree of precision of TIMESTAMP, log in. The chances of collision are sufficiently slim as to be ignored, but it’s important to note that it is possible.)
I should have changed unique id to auto-increment. I’ve never heard the term surrogate key…learned something new…
Yes, it’s theoretically possible that two computers for the same user could have the exact same login timestamp, but I would argue that the chances are so insignificant to render it nearly impossible. Time stamps are defined so granularly, the chances of this situation occurring are not worth considering.