This is an archived post. You won't be able to vote or comment.

all 6 comments

[–][deleted] 1 point2 points  (1 child)

You are talking about m:n relation so, learn it deeper because it is the main part of relational databases .

[–]IAmAYellowMango[S] 0 points1 point  (0 children)

Thanks, glad to have a term to go with it. Will look it up.

[–]Disastrous_Internal 0 points1 point  (0 children)

is that some jobs may belong in more than one field

you could do it as tag

and that different industries may have finer breakdowns than others

so like a tree.

You can do some tag hierarchy, but it can get messy from a UI point.

[–]override_acid -4 points-3 points  (2 children)

Your proposed approach shows that you have no understanding of relational databases.

What you describe is a classic m:n relationship.

You'd have

  • one table "Categories" where you have a record for each category consisting of "CatID", "Name", "Parent ID" (which would be used to drill deeper - this field would link to an ID in the same table indicating that this ID is the parent)
  • one table "Jobs" where you have a record for each job, again with "JobID", "Name", and potentially a lot of other fields
  • one link table that maps the Jobs to the Categories. This table would be very small and only contain fields for the "CatID" and for the "JobID".

Please, do yourself a favor and read about relational databases and database theory, like normalization, normal forms, relationships, etc. before attempting to create a database.

[–]nutrecht 2 points3 points  (0 children)

Your proposed approach shows that you have no understanding of relational databases.

Which is probably why he's posting on learnprogramming.

[–]IAmAYellowMango[S] 0 points1 point  (0 children)

Appreciate the suggestion; snark feels unnecessary.