Question

I use a table GadgetData to store the properties of gadgets in my application. There gadgets are basically sort of custom control which have 80% of the properties common like height, width, color, type etc. There are are some set of properties per gadget type that the unique to them. All of this data has to store in database. Currently I am storing only common properties. What design approach should I use to store this kind data where the columns are dynamic.

1. Create table with common properties as Columns and add extra column of type Text to store the all unique properties of each gadget type in XML format.
2. Create a table with all possible columns in all of the gadget types.
3. Create separate table for each type of gadgets.
4. Any other better way you recommend?

(Note: The number of gadget types could grow even beyond 100 and )

Answer 1

Option 3 is a very normalized option, but will come back and bite you if you have to query across multiple types – every SELECT will have another join if a new type is added. A maintenance nightmare.

Option 2 (sparse table) will have a lot of NULL values and take up extra space. The table definition will also need updating if another type is added in the future. Not so bad but still painful.

I use Option 1 in production (using an xml type instead of text). It allows me to serialize any type derived from my common type, extracting the common properties and leaving the unique ones in the XmlProperties column. This can be done in the application or in the database (e.g. a stored procedure).