Question

We currently have a settings hierarchy in our system that allows settings to be saved for an individual user, a setting group (each user can be tied to a single setting group, but the setting group is in a nested set so we query up the tree to check for inherited values from parent setting groups), or customer level settings (each user can be tied to one customer).

Currently we have three tables storing the setting values for each level:

• user_setting_values
• setting_group_setting_values
• customer_setting_values

I have been asked by management (also the dude who originally wrote the system) to merge these tables into one single table that holds all the settings. He hasn’t come up with a particularly good argument for doing it other than “it makes sense to have them all in one table”.

So is this a good idea? What are the pro’s and con’s?

Answer 1

Pro: Less tables
Con: Always a good idea to avoid nulls, concolidating different levels normally leads to nulls values

If concolidated into one table there is typically two solutions for implementation

1. Using a type column if type of settings are the same per level, value reflects which level data relates to, e.g. user, group or customer.

2. Expand number of columns if setting types are different per level

Nulls used to indicate N/A values for a given column

If settings is of type yes/no storing value as booleans might be handy.