×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Normalization Question? Have I gone too far......

Normalization Question? Have I gone too far......

Normalization Question? Have I gone too far......

(OP)
Ex. tblCompany stores city, state, name, zipcode, etc.
tblAddress stores Address Line 1, 2, 3, 4.

Using a FK relationship I store the address information about the the company in tblAddress. When needed I use the appropriate join and voila. I am also doing the same with phone numbers in respect to a customer. Have I gone too far? Is this common practice to normalize to this level?

My intentions were to eliminate as many null fields in the database as possible.

Scott
Programmer Analyst
<><

RE: Normalization Question? Have I gone too far......

From a practical point of view, this is to far, store the addresses in a memofield, if they are that big. Storing in multiple tables also main more processing for retrieving the data.

Steven van Els
SAvanEls@cq-link.sr

RE: Normalization Question? Have I gone too far......

I don't think it's going too far to have a separate address table. Yes, you will pay a small performance penalty doing a join. The advantage is decoupling your other tables from the details of addresses. In addition to companies, do you have tables for employees, divisions, etc. that have addresses? If so, they can also use this table.

When it comes time to make a change (adding additional fields to handle foreign addresses, for example), you can do it in one place, not several.

Unless this is a huge, time-critical database, developer maintenance costs will usually far outweigh the performance costs of a separate table.

RE: Normalization Question? Have I gone too far......

Normalisation is used to break out repeated information.
So splitting an address into 2 parts is not part of normalisation, so you have gone too far.

If your personal preference is to do it though, then go ahead.

You should only get tables whose relationship is one to many at the end of normalisation. Many to Many needs an intermediate table and One to One (yours) is unnecessary splitting information.

RE: Normalization Question? Have I gone too far......

(OP)
BobWhiteField,
I have a contact(could be employee) table, company table, address table.

tblContact contains a FK to tblCompany's PK
tblAddress contains a FK to tblCompany's PK

So inorder to retrieve a contacts information I will need to join 3 tables.

Little Havoc,
I understood the final relationship between the two tables is 1:M or more specifically 1:4.

You are correct that normalization is used to break up repetative information. However, it is also used to reduce the number of null values in a database.



Thank you all for you comments.

Scott
Programmer Analyst
<><

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close