In a recruiting website, should I force a choice between one table for jobseekers and employers or 2 separate tables?

Question

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?

Answer 1

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?