database design - empty fields

Posted by imanc on Stack Overflow See other posts from Stack Overflow or by imanc
Published on 2010-05-01T20:48:47Z Indexed on 2010/05/01 20:57 UTC
Read the original article Hit count: 183

Filed under:
|
|
|

Hey,

I am currently debating an issue with a guy on my dev team. He 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.

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.

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.

His 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.

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.

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.

So my question specifically: -

if you have slight variances in data for each record (1-2 different fields for instance) what is the best way to proceed?

© Stack Overflow or respective owner

Related posts about mysql

Related posts about design