title: Normalize or Denormalize: Store Contact Details (Phone Numbers) in separate Table? Search Performance?
body: <p>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.</p>
  
  <p>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:</p>
  
  <pre><code>Id int PK
  ContactId int FK&lt;-&gt;Contacts.Id
  PhoneNumber nvarchar(22)
  Description nvarchar(100)
  </code></pre>
  
  <p>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).</p>
  
  <p>However, I end up with an "ugly" structure like this:</p>
  
  <pre><code>PhoneNumber1 nvarchar(22)
  Description1 nvarchar(100)
  PhoneNumber2 nvarchar(22)
  Description2 nvarchar(100)
  </code></pre>
  
  <p>etc. etc.</p>
  
  <p>It looks amateurish to me but here are the advantages I see:</p>
  
  <p>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.</p>
  
  <p>2) No SQL Join necessary to retrieve the information.</p>
  
  <p>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 <strong>search</strong> for a phone number I'd have to look at 4 fields instead of 1 if I kept it in a separate table. </p>
  
  <p>My application has about 80% search/data retrieval activity so search performance is an important factor.</p>
  
  <p>I appreciate your help in finding the right way to do this. Separate table or keep it all in one? Thank you!</p>