I would have this asked on StackOverflow if it had code, but it's more on the idea/concept so I asked here.I am working on the UI of our inventory system when I found out that when registering a user in the system, the username and password of the user is optional. I asked our supervisor why is this so. He said that in the system, there are bins of assets (think of boxes with toys) where we assign through the system employees to handle these bins. Employees must be registered in the system but some of them are not given access to the system, therefore there is no use giving them usernames and passwords.But I think his argument is wrong, really wrong because every time I hear no username no password makes me cringe as it is most synonymous to a no-password, free-to-access account. And so I ask:What would be the correct database design to separate this system-user employee and non-system-user employee that does not use this no username, no password scheme?Currently, as the description implies, we have a single table with uid, username, hashed password and other fields with additional user data.To prove to him a point, I would like to know why storing a blank username and password for an account is totally wrong for non-system-user registered employee.What are alternatives to having this system? I know it's best to keep in one table the registered users but I have never seen this situation where there are registered users that don't have access to a system. It's like you are given a Facebook account, profiles and all but don't have a username and password for it (or in this case, blank)
User management data - the need for a username and password
security;database design
I would suggest 2 separate entities - employees that can be assigned to handle bins, and registered users.You could link the registered users to their employee records.That way you won't have spurious employees with blank username / passwords.