title: MS Access Schema Decision: Multiple Tables or a lot of Null Values?
body: <p>I found this thread which helps my understanding somewhat, but does not answer my question:</p>
  
  <p><a href="https://stackoverflow.com/questions/2116719/sql-using-null-values-vs-default-values">SQL: Using NULL values vs. default values</a></p>
  
  <p>My Question:
  If I am creating a schema (in an MS Access Database) that is designed to store contact information for employees, would it be better to have a single table for telephone numbers, then a single table for addresses, then another single table for email addresses, OR would it be better to have a single table that stores all of these records, but might have NULL values for several of the fields in more than half of the records?</p>
  
  <p>I would like to store the different elements of a street address into separate fields: <strong>For Addresses:</strong> one field for the street number and name, one filed for the city, one for the state, one for the country, one for the zip code, and also one for any other name for the address ("ATTN:" or similar), and maybe more; <strong>For Telephone Numbers:</strong> essentially one for a name and one for a number; <strong>For Emails:</strong> essentially the same as Telephone - name and number. This would leave many NULL/Blank values in the list for telephone numbers... in fact, I would estimate probably 70% of the records would have 5 or more null values, on the scale of 5,000 to 10,000 records.</p>
  
  <p>I would want to be able to display them both in separate lists as well as in a combined list, filtered and grouped. Either structure could support this (through JOINS/UNIONS and WHERE clauses). In terms of simplicity of table structure, a single list would seem obvious - ONE table is "neater" than three or more tables. </p>
  
  <p><em>The answer, I think,</em> should hinge on the efficiency of "storing" potentially tens of thousands of NULL values vs. the efficiency of indexing different tables, and spending time ensuring UNIONs line up with datatypes and constructing various other methods to combine data that is already SOMEWHAT related.</p>
  
  <p>I hope I have presented my thoughts clearly enough! I welcome links, answers, and comments as well as questions.</p>