Let's do this verbally and maybe the database structure will become 
intuitively apparent....

You are hosting a website that supports job seekers (maybe more but let's 
concentrate on just this side of it)

Each seeker (a User) can have a profile in the system
Each profile describes who the User is (name), where they are (address, 
email address) and how to contact them (main phone, cell phone)
Associated with each user is a list of up to 10 industries they have 
belonged to.
Associated with each user is up to 5 resumes.
Each user can be looking for employment in any of 5 locations
Each user can be looking for employment in any of 5 industries
Each user can look for employment under up to 5 different job titles.

Please take the time to correct me and fill in any gaps. Please DO NOT 
attempt to make any data definitions at this stage. I need to understand 
what data you are going to maintain verbally before I can help you 
translate it into storage requirements.

Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine

Stuart Felenstein <[EMAIL PROTECTED]> wrote on 10/06/2004 02:47:44 PM:

> Shawn, 
> 
> When I read your examples, it is clear as a bell. 
> When I try to map it into my situation it becomes more
> difficult to clarify :)
> Using other job boards as examples, there are a couple
> of ways to go.
> Most of the bigger players offer job seekers the
> ability to store 5 resumes online.  These are not just
> the actual resume though and are part of a "profile". 
>    5 profiles can be targeting or positioning the job
> seeker to 5 different types, jobs, locations. 
> 
> Method 1:
> User Table: MemberID, username, password,.....
> 
> Profile_Table: RecordID, MemberID, locationfield,
> jobtitle field
> 
> Industry_Table: MemberID, LocationID, ProfileID
> 
> User_Profile_Table: MemberID, ProfileID, LocationID
> 
> Then I wonder about the "job_titles" field.
> There is a "current" job title, a "seeking" job title
> and an alternate job title.
> 
> Do I implement: 
> JT_Current_Table
> JT_Seeking_Table
> JT_Alternate_Table
> 
> Same thing with inudstries. Database designers can
> work in many industries,so can other workers. Users
> can choose 10 inudstries:
> 
> Is there a need to have 
> Industry_1_Table
> Industry_2_Table
> Industry_3_Table
> Industry_4_Table.....
> 
> All I can say is I believe this would be a better
> design, but I can't get passed thinking, what for ?
> Why not 
> 
> Profile_Table:
> RecordID:
> MemberID:
> Industry1
> Industry2....
> ....
> JobTitle1
> JobTitle2
> ..............
> 
> Like I say at the start here, difficult to apply to my
> situation.  Maybe because it doesn't apply, but at the
> same time I can't see the implications of doing it via
> the last method.
> 
> So, as painful as it's been for you with me, I'll ask
> if you see potential problems or what the issues could
> be to point them out to me.
> 
> Thank you,
> Stuart
> 
> 
> 
> 
> 
> --- [EMAIL PROTECTED] wrote:
> 
> > (I guess this means it's  example-counterexample
> > time....)
> > 
> 

Reply via email to