--- [EMAIL PROTECTED] wrote: > 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....) > > > > > >
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
