Question

I’m designing a database application which stores simple contact information (First/Last Name etc.) and I also have to store phone numbers. Besides phone numbers I have to store what they are for (mobile, business etc.) and possibly an additional comment for each.

My first approach was to normalize and keep the phone numbers in a separate table, so that I have my ‘Contacts’ and my ‘PhoneNumbers’ table. The PhoneNumbers table would be like this:

Id int PK
ContactId int FK<->Contacts.Id
PhoneNumber nvarchar(22)
Description nvarchar(100)

However, it would make things a lot easier AND save a SQL Join on retrieval if I just stored this information as part of each contact’s record (assuming that I limit the total # of phone numbers that can be stored, to say 4 numbers total).

However, I end up with an “ugly” structure like this:

PhoneNumber1 nvarchar(22)
Description1 nvarchar(100)
PhoneNumber2 nvarchar(22)
Description2 nvarchar(100)

etc. etc.

It looks amateurish to me but here are the advantages I see:

1) In ASP.NET MVC I can simply attach the input textboxes to my LINQ object’s properties and I’m done with wiring up record adds and updates.

2) No SQL Join necessary to retrieve the information.

Unfortunately I am not very knowledgeable on issues such as table width problems (I read that this can cause problems if it grows too big/too many columns and that performance issues come up?) and then also it would mean that when I search for a phone number I’d have to look at 4 fields instead of 1 if I kept it in a separate table.

My application has about 80% search/data retrieval activity so search performance is an important factor.

I appreciate your help in finding the right way to do this. Separate table or keep it all in one? Thank you!

Answer 1

It won’t likely cause problems to have the data denormalized like that, but I wouldn’t suggest it. Even though it may be more complex to query, it’s better to have well formed data that you can manipulate in a multitude of ways. I would suggest a database schema like this:

Contacts:
  ID (Primary Key)
  Name
  Job Title

Phone Number Categories:
  ID (Primary key)
  Name

Phone Numbers:
  ID (Primary Key)
  Category_ID (Foreign Key -> Phone Number Categories.ID)
  Contact_ID (Foreign Key -> Contacts.ID)
  Phone Number

This allows you a lot of flexibility in the number of phone numbers allowed, and gives you the ability to categorize them.