3

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. 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?

  • 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. – Nicolas de Fontenay Mar 29 '11 at 13:32
7

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?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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