Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm working on a recruiting web site and I was wondering what would be best between:

1) A User table, the employer accounts are linked to a company (therefore when companyID is null then it's a job seeker) 2) 2 complete separate tables one for job seekers, one for employers. That way on the long run, it's possible to optimize queries a bit more if it becomes hugely successful.

Both approach have pros and cons:

With 1) it would be possible for exemple to create only one login form which would handle both job seekers and employers.

The data is the same but the entity is different.

I have mixed feelings. What do you think?

share|improve this question
    
Somebody with an employer account can't be a job seeker. They would need a different account for that. But the link to company table would take care of that. –  ndefontenay Mar 29 '11 at 13:32
add comment

1 Answer

up vote 4 down vote accepted

From a user experience point of view, it would be much easier to support only one "login method" without having to select which type of login a user wants to do (e.g. a dropdown for job seeker/employer). This would also mean all usernames would need to be unique.

If you separate the tables, you can still have optimal queries, they just might have an extremely small join associated with them (or just create a denormalized view of both job seekers & employers and you have best of both worlds!).

I think the real question you should ask is: Do job seekers & employers have fundamentally different data associated with them or is there a large amount of overlap?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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