Forum Academy Marketplace Showcase Pricing Features

Data Structure Advice

Looking for some database advice, I am building a niche industry jobs/careers site. There are 2 distinct types of users: candidates (who will create profiles, search for and apply for job postings) and employers (who will create a different type of profile, browse candidate profiles, and post jobs).

So let’s say that a candidate user profile has 10 fields and an employer user profile has 10 completely different fields. How should I design the User data type around this?

Option 1) should i have all 20 fields (10 for candidate and 10 for employer) in the user data type plus another field for Account Type (candidate or employer), and have the fields will be empty for a given user type?

Option 2) should I have separate data types for Candidate Profile and Employer Profile and then keep the User data type be really thin and only have it contain an account type attribute and then one to one data types for Candidate Profile ID and Candidate Profile ID to reference those profile data fields?

This is my main concern at the moment, but I also face a similar question about job postings, as there are 2 completely unrelated job posting types with completely separate data attributes. I could create 2 separate data types, one for each type of listing (they dont need to appear in the same queries ever), or I could have one listing type with lots of fields, half of which will be N/A for a given posting.

Like most things, it will be entirely dependant on the specifics of your app as to which approach is best in your case.

Personally, I’d use (and do use) the second approach here, although it really depends on how much data you’re planning to store (20 fields in total doesn’t seem like a lot to me, so using a single User datatype might work just as well in this case).

But personally I’d have an option set for ‘User Type’, then on the User datatype have a field for User Type (which may be a list), a field for Candidate (of type ‘Candidate’), and a field for Employer (of type ‘Employer’), along with other basic User Data, like name, photo, etc.

Then all the more complex data can be stored on the separate datatypes.

But again it really depends on the type and quantity of data you’re intending to store, and how you intend to access it.

Thanks Adam, very helpful. I was guessing that would be the response with a healthy caveat of “it depends”, but for Option 2 I wanted to make sure I was thinking through that correctly so this was exactly what I needed.

1 Like