|
| |
|
|
jsims
Posts: 42
From: Denver CO USA
Status: offline
 |
DB design question - 3/8/2001 16:31:00
I know that good database design recommends breaking data into discrete, linked tables that store a single type of information each. For example, I'm building an Access database for an association which I will link to our FP website. I'm thinking about starting with a table of member names; then breaking up additional information (member addresses, member contact info, the companies that each member belongs to, the status of each member's dues, etc.) into separate tables linked to the first one by the unique id of each member.My dumb questions are these: 1) If I want to update a member's contact info in a "sub" table, won't I have to first look up the member's unique ID in the main table, then match up that ID in the linked table to edit the proper record? Or, is there a better way to do this? I can see a lot of room for error by screwing up on matching up the right ID number from the main record. 2) Does breaking up data into these tables really help with performance? It seems easier from a data management standpoint to work with one large table instead of a bunch of smaller ones. However, maybe that leads to slower query execution. Any thoughts here? Thanks! Jim Sims
jsims@policycom.com
|
|
|
|
Elecia
Posts: 68
From: orlando
Status: offline
|
RE: DB design question - 3/8/2001 17:35:00
Oh no don't do that! You should have a single type of info in a table but what your talking about going is an extreme. I would
keep these fields in the same table member addresses, member contact info, the companies that each member belongs to. I might split the dues info into a serpate table if the will be more than a field or two. Say for instance if you wanted a date last paid field, amount last paid, amount due, date due etc. then I would definitely split it out into a serperate table and use the member id fields to link them. You might want to take a look at the nwind.mdb that comes with office to get an idea of how to group your data.
EE[This message has been edited by Elecia (edited 03-08-2001).] [This message has been edited by Elecia (edited 03-08-2001).]
| |
|
|
|
jsims
Posts: 42
From: Denver CO USA
Status: offline
|
RE: DB design question - 3/12/2001 20:21:00
Thanks, Elecia and Vince, for the feedback. As an obvious database newby, I'm breathing a sigh of relief. The Microsoft piece was good, Vince ... thanks for the link. I must say, however an extensive article on normalization from Webmonkey got me thinking I needed to do this in the first place. I think I have a better handle on what practical normalization means now.
Best,Jim
| |
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts
|
|
|
Printable Version 
![]("http://www.frontpagewebmaster.com/ubb/wink.gif")
