title: Database design - empty fields
body: <p>I am currently debating an issue with my dev team. They believes that empty fields are bad news.  For instance, if we have a customer details table that stores data for customers from different countries, and each country has a slightly different address configuration - plus 1-2 extra fields, e.g. French customer details may also store details for entry code, and floor/level plus title fields (madamme, etc.). South Africa would have a security number.  And so on. </p>
  
  <p>Given that we're talking about minor variances my idea is to put all of the fields into the table and use what is needed on each form. </p>
  
  <p>My colleague believes we should have a separate table with extra data. E.g. customer_info_fr.  But this seams to totally defeat the purpose of a combined table in the first place. </p>
  
  <p>The argument is that empty fields / columns is bad - but I'm struggling to find justification in terms of database design principles for or against this argument and preferred solutions.</p>
  
  <p>Another option is a separate mini EAV table that stores extra data with parent_id, key, val fields.  Or to serialise extra data into an extra_data column in the main customer_data table.</p>
  
  <p>I think I am confused because what I'm discussing is not covered by 3NF which is what I would typically use as a reference for how to structure data.  </p>
  
  <p>So my question specifically: -</p>
  
  <p>If you have slight variances in data for each record (1-2 different fields for instance)  what is the best way to proceed?</p>