Question

I am currently working on an application which references the Microsoft Business Contact Manager SQL Server database add-on for Outlook. The main Contact table in the db has several sub tables which have identical keys to the main table and a small number of columns; for example, an email address table which has 3 columns: contactID, EmailAddress, and EmailDisplayAs. Because of this approach, you need to use a view with multiple outer joins just to see all the columns which make up each Contact record. I have never seen a database with this kind of structure; it seems messy to say the least. I would be interested to see comments on why one would take this approach.

Answer 1

Basically there are two general approaches to optional data:

1. Include them in the tablea s nullable (ie optional) columns; or
2. Use one-to-one relationships to child tables that contain logical groupings of attributes.

Personally I think that unless you’re dealing with an extremely large number of optional attributes you should favour nullable columns. The overhead is so low it’s negligible–particulalry when compared to doing lots of joins. Plus if you have child tables via one-to-one relationships you’re storing the primary key again (as a foreign key in the child table) so any storage overhead of nullable columns is in fact less.

But anyway, that’s all that is.