> I'm designing a survey which will have a lot of drop down lists for foks to > pick their choices, thus avoiding entry mistakes and making entry quicker > for them. > > I had originally created a million (ok about 25) "code" tables, one for > each code type, such as "computer type", "vendor" or "language". I realized > it would be more efficient to combine all of these into a "allcodes" table > which has 3 fields, the codetype (i.e. what category of lookup code is > it?), the actual code I'd previously assigned (00123, 00124, 00125 etc.) > and a description field containing the name to be displayed on the drop > down boxes. I figure I can then use a combination of codetype and code for > my key fields in my data tables. > > I'm not entirely sure how I want to do this and can't believe I'm inventing > anything new. Do any of you have any samples/ideas to share or point me > towards info on this approach... and if you think it's the right one ;^)! My recommendation is to maintain 25 separate tables. In my experience the 'simple lookup table' is always the first thing affected by feature creep. For the 'Vendor' code, for example, you may ultimately want to store the address, phone, fax, e-mail, etc. For the 'Computer Type' you may want to expand beyond 'Apple', 'Compaq', 'Sun' etc. to store the OS that can run on each. For the 'Language' (I'm assuming Computer language, as opposed to Human language here), you may want to store the developer and version. Having a 'Smart' update routine that can handle all of this is much more of a headache than having 25 edit routines that are based on a single class, and then have additional fields. /Paul