Jason
If you think about it, in real life, a person can have:
many degrees Germans even list them all on their business cards, e.g.,
Herr Doktar, Doctar, Doctar
More than one company
These logically belong in a one-to-many relationship
HTH
Dick
At 9:52 AM -0700 3/20/01, Jason Lotz wrote:
>This is more of a theory question than an actualy request for help. Let's
>say you are building a database of members with lots of information that
>applies to every member (name, address, phone, etc.) This could be about 40
>seperate fields. Then, on top of that, each member can have lots of
>optional information that can easily be grouped together. For example, if
>they graduated from college, you want to store their degree information or
>if they own a company, you want to store their company info. Each of these
>"optional groups" are one-to-one (each member can only have one chunk of
>this data but doesn't have to have it at all.) Now here's the question -
>
>When you are building this database, you could easily put it into one huge
>table because all the information is one-to-one. However, it's a pain when
>you only want to get the "degree" information or the "company" information.
>From a programming standpoint, is it best to break these into smaller tables
>for ease of use or to keep it into one table?
>
>Thanks,
>Jason
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
