views:

54

answers:

3

I am trying to develop a database model for a recruitment website and I have a lot of confusions.

  • Job seeker can make 5 resumes online. In location field he can add 5 locations at most.
  • Job seeker can fill up a form and jobs will be emailed according to the fields that he filled up. In this form he can select as many locations as he want.
  • Job Poster can Posts job. And he can add as many locations as he want in job form.

I have created a location table with all the locations. Now I am confused how locations will be saved in resume, jobEmail and jobAd table?

I can think of two solutions.

  1. There will be a locations field in each table and all location IDs posted from forms will be saved in this field separated by commas. And later on I can use some mySql function to match these locations.
  2. Create another table for each table with columns say resumeId, locationId, and all locations will be saved as a separate record in this table.

Which of these solution is right? Or is there an other way for this kind of scenarios.

Thanks

+4  A: 

Create another table. Never, ever store data as comma-separated values. "Never, ever" might be a slight exaggeration but in most circumstances you'll be best served storing the data in a table so you can apply normal SQL queries to it without having to parse the comma separated data.

In other words, the second approach is the optimal one.

Rob
+1 for "never,ever comma seperated"
DrColossos
I second "never,ever comma separated" however, in that case, I sense that locations is just 5 magical text fields, that would never be processed by SQL (unstructured data, nothing doable in SQL). So I'd use some magical separator (char(253), a-la-PICK) to store the multivalued attribute...
pascal
i have to store locations, sublocations, classification, subclassification, work types for each entry in resume, jobAd, emailJobs table. So i will make ( 5 x 3 ) tables? For example, jobAd table will have say jobAdId and jobTitle fields and there will be another table jobAdLocations and it will have jobAdid, locationId fields. And say job ad is for 50 locations then there will be 50 entries for one jobAd in jobAdLocation table?
mysterious
@mysterious - storage space is cheap! =) If an ad is for 50 locations, have 50 records in the jobAdLocation table. For example, if you wanted to find all jobs that have location 33, it's a lot easier with a jobAdLocation table (`SELECT * FROM jobAdLocation WHERE LocationId = 33`), than a comma separated value. Especially if you want all that have Location 33, but don't have location 32, for example....
Rob
@pascal, perhaps I should have said "never, ever *anything* separated". If you're using a database to store relational data, play to its strenghts.
Rob
Thanks Rob, you are cool
mysterious
A: 

I would have all these "classifications" or "objects" as a seperate table. This will breed extensibility when the requirements change (they always do).

Then control the fact they are only allowed 5 through code, either in a stored procedure or via php, or c#, does not matter really.

jimplode
+1  A: 

alt text

Damir Sudarevic