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]
