Re: Job listings DB

> Hi, > > I am designing a system for my company to get employee resumes via the Web, > rather than paper. All resumes now go into a mySQL DB, which can be > searched by HR (at least that's the theory :) [I would do it like that also] > > My questions: > > For job listings - how do I design the tables? Can I dump all job listings > into a single table, and all applications/resumes into another one? Or > should they be normalized? [They should be normalized] > If normalized - how much? For example, in a listing, I have job code, > department, location, salary range, etc. - should I have separate tables > for each of these? Like [Yes, I would say so] > jcode dept loc > 1 213 2 > 2 77 3 > > where dept and loc are FKs to other tables? Or is this taking it too far? [It is not a necessity, but it would be easier to modify or upgrade later, wich we always do] > Same for application form. All this information that I am getting - should > I put into a single table, or split across separate tables? I do plan to > search by differenet criteria later. > > What about items in drop-downs? For example, if I have a drop-down for > salary ranges or countries - should this information come from a table, or > should I hard-code into the form itself? How do I make the decision as to > which is appropriate? [I would never hard code anything that can change, salary ranges can changes, country can change too :) ] [Besides, in what I call Code Table like country I would have 3 fields: country_id, country_name, country_zorder, you increment country_zorder by 5 The reason: You can later order by country table by name, by id or by a specific order that you defined (putting more popular country on top)] > Any assistance much appreciated. TIA, > > Vikram > -- > Give a homeless man a bundle of firewood, and he'll be warm for one day. > Douse him with a gallon of gasoline and set him on fire, and he'll be warm > for the rest of his life! [ouch!]