Results 1 to 1 of 1
Dec 20, 2004, 03:00 #1
- Join Date
- Jun 2004
- Stockholm, Sweden
- 0 Post(s)
- 0 Thread(s)
DB Design, data from different tables related to one item.
Hello everybody, it's been a long time since I last posted on Sitepoint.
I have a design problem I need help to work out.
I need to create a database holding information about hardware items, and these hardware items are joined together in so called Nodes.
Each node can contain many types of hardware, and each type of hardware needs to hold different type of information based on which kind of hardware it is.
So far, my idea is this:
tNodes - Master node list
Node ID, primary key identifier
tNodeContents - Link between node and hardware.
NodeID, foreign key link to tNodes
HWID, foreign key link to hardware table
HWTypeID, ID identifying the type of hardware.
tHWType - Multiple tables, one per HW type to contain the info for that HW type.
HWID, primary key identifier
(HW Data), HW data fields as needed for the HW type.
And the driving application would examine the HWTypeID and look up the proper table based on that value.
Now this is far from an optimal solution, but I can't think of a better one. I mean, how would I determine which HW table to look in to get info of what HW is in each node?
Since each type of hardware can contain an enormous amount of information and not all of it is shared between each HW type, I can't make tables of HW information and link to HW like that (too few common fields between the HW).
Do you think I should go with my idea above, or do you have suggestions on how I can improve the design?If there is a way to overcome the suffering, there is no need to worry; if there is no way to overcome the suffering, there is no point to worry.