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)
2
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.
It sounds like the employees who are in the system but have no username/password are a special class of employee, let’s call it “bin-handling employees” from your description: “we assign through the system employees to handle these bins”.
You could move these special employees to a separate “bin-handler” table. Also, move the usernames and passwords to a table just for that. That way you can still assign these employees to bins of stuff, but they are not in the same table as the table with usernames and passwords. You could then reference the main Employee table through a foreign key.
If splitting into separate tables isn’t going to work for you, you could have a “can log in” field, which tells the system if that Employee is allowed to log in, or if they only exist to be assigned to bins.
2
It may not be that important which way you do it, but having a user table and an employee table might make more sense. At this moment you have employees that are not users, someday you may have users who are not employees. Making them separate probably models the world a little bit better.
On the other hand, it may be that you can encapsulate your code such that making the change later will be easy. In that case, you can just do the quickest thing now and worry about it when the time comes.