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)

  • The "employees" who don't have user names or passwords - can they actually do anything on this system? Such as create/modify/delete data? How are they "not given access to the system"? Is it by denying them access to terminals where the system runs? Or not telling them the URL? Or something else? Jul 20, 2012 at 17:00
  • @FrustratedWithFormsDesigner They are just recorded in the system along with the system-users, but are not allowed to login to the system.
    – Joseph
    Jul 20, 2012 at 17:05

3 Answers 3


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.

  • But they also have this idea that "there will be a time that a bin-handling employee might be given access", and so, one can just add a username and password to him for him to access the system. I guess the "can log in" field would suffice.
    – Joseph
    Jul 20, 2012 at 17:13
  • Or you could just have one user table and specify permissions and groups of users to know how to restrict them.
    – Rig
    Jul 20, 2012 at 21:14

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.