DB design question

	Home Register Search Help Login

Sponsors
Frontpage website templates
Creative Website Templates for FrontPage, Dreamweaver, Flash, SwishMax
Shopping Cart Software
Ecommerce software integrated into Frontpage, Dreamweaver and Golive templates. No monthly fees and available in ASP and PHP versions.
Website Templates
We also have a wide selection of Dreamweaver, Expression Web and Frontpage templates as well as webmaster tools and CSS layouts.

Recent Posts
Todays Posts
Most Active posts
Posts since last visit
My Recent Posts
Mark posts read

DB design question

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> Web Development >> ASP, PHP, and Database >> DB design question

Page: [1]

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).]

(in reply to jsims)

Vince from Spain

Posts: 658
From: Madrid Spain
Status: offline

RE: DB design question - 3/8/2001 17:46:00

Hi Jim,
the process you are talking about is called Normalization, and there is a pretty good discussion of it with some quite clear examples on the msdn . . .
http://support.microsoft.com/support/kb/articles/Q100/1/39.asp

Good point by Elicia . . . don't *over* normalize

All the best

Vince

------------------
Internet Business Solutions S.L.(Spain)

(in reply to jsims)

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

(in reply to jsims)