I'm creating a web-app that will connect to a MySQL database. This app will have 2 users: a Staff and Client that can both log in from the same login page.
Both Staff and Client share the following common attributes:
- staffID/clientID
- status
- timestamp update
- username
- password
- image profile
- first/middle/last name
- gender
- date of birth
- address
- phone
But the Staff has the unique attributes:
- position
- license
- badge
- date hired
And the Client has the unique attribute:
- company name
1.) Would it be advisable to put all the common attributes in one single Users
table with a column user_type
to determine whether it's a Staff or a Client that logs in or make two separate tables for Staff
and Client
that have the exact same attributes?
2.) Would it be advisable to further separate the following attributes:
- gender
- date of birth
- address
- phone
into another table since they will not be queried as much (these attributes are only queried when viewing users' profiles)? Will this help speed up query time for, say, log ins?
3.) Would it be ideal to separate the image profile
attribute into one table Image_Files
or keep it within the same table with all the other attributes?
As of now, I'm leaning on making the following tables with columns:
USERS
table:
- userID [PK] (formerly staffID/clientID)
- status
- timestamp update
- username
- password
USER_DETAIL
table:
- user_detailID [PK]
- userID [FK]
- gender
- date of birth
- address
- phone
STAFF_DETAIL
table:
- staff_detailID [PK]
- userID [FK]
- position
- license
- badge
- date hired
CLIENT_DETAIL
table:
- client_detailID [PK]
- userID [FK]
- company name
IMAGE_FILES
table:
- imageID [PK]
- userID [FK]
- image pathfile pointer
Is this database design unnecessarily complicated? If so, how may I streamline it to make it more simpler, faster to query, and yet still satisfy the unique attributes of each entities?
Best Answer
I think your problem is that you are focusing to much on performance. From the description it seems like the user table will be rather small (say, less than a million users).
Instead you should focus on the functionality you want from the system. There are questions you should ask and design for such as:
My take on this is that I would have one table describing a login user and a second table describing a users role. When a user has successfylly logen in I would check if the users has several roles, and the user would be required to select role: staff or user for one company. This would allow the login to be for one physical person, over time it could evolve to include OTP or challenge response or what is deemed necessary. The user would at any time have zero, one or more selectable roles.
Edit (added): If the user has only one role, there is no need to show any selection. Even if a user has no role right now the system might allow changing adress, mail adress and so on. Role based might allow a user to be administrator for the users at one company. End edit.
In the role table I would have start and stop dates. If necessary from a performance view it would be possible to later add an "active" field but that would be an optimization which I would not add until necessary.