This is how I would handle it. It sounds like a standard many-to-many relationship.
At 10:17 AM 01/30/2002 -0800, you wrote: >I'm putting together a new database for a fairly substantial application I >need to build. > >Here is the kind of information I need to store: > >-- Registration of individual (standard name, address, email type of stuff) >-- Categories of interest > >The categories of interest will come from a predefined table of about 100 >choices. The user will be able to make multiple selections. > >Here is my tentative plan on how to store this information > >UserTable (UserID, name, address, etc.) >CategoryTable (categoryID, categoryName) >CategoryMatchTable (CategoryID, UserID) > >This last table would store one row each for each categoryID selected by the >User matching it with each UserID. > >I've used this method on similar problems before, but I thought I would post >the question here and see if any of you great minds know of a more elegant >way to do this (match users with multiple selections from a list generated >out of another table). > >H. > ______________________________________________________________________ Why Share? Dedicated Win 2000 Server · PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation · $99/Month · Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionc FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
