Re: Database design problem - resolving many-many relationships

From: Lennart Jonsson <lennart_at_kommunicera.umea.se>
Date: 22 May 2002 20:30:23 -0700
Message-ID: <6dae7e65.0205221930.7bb712ea_at_posting.google.com>


vrhash_at_yahoo.com (Ramani) wrote in message news:<d49237dd.0205221017.7b26bb03_at_posting.google.com>...

[...]  

> Now, what i've thought of is to resolve the many -many relations by
> creating a table for the relations.
> The part I am most confused about is the hard drives and Network
> addresses.A comp may or may not have more than 1 hard disk. Same goes
> forthe Network addresses. So, it make sense to create a separate table
> for the relation -
> in the case of hard disc and Network addresses..
>
> comp_hard_disk( comp_id foreign key references comp_details
> hard_disk_id foreign key references hard_disk)
>
> comp_network_addr( comp_id foreign key references comp_details
> addr_id foreign key references network_addr)
>

I would say that this is the way to go.  

>
> This would be too tiresome since I have almost 600-700 comps to deal
> with.
> Also, the no. of addresses will run into thousands.

I'm not sure I follow, what is the problem with a couple of thousand things?  

> Should I just go ahead and create 2 columns for hard disks in
> comp_details table as Hard_disk_1 and hard_disk_2 and create 4 columns
> for addr as mac_1, mac_2, mac_3, ip ?
> This violates the normalization rules..

If you had a fixed amount of for example addr, then perhaps. Otherwise I would advise not to. Consider for example the number of OS you can run on a standard PC

   RH, Suse, FreeBSD, Win, OS/2, etc (not to mention different versions)

I you make room for x nr. of os, I'll bet there will be x+1 nr. of os on some pc within polynomial time :-)

/Lennart Received on Thu May 23 2002 - 05:30:23 CEST

Original text of this message