App Configuration and Databases

Jeffrey “Party With” Palermo recently posted on “Separating configuration from data lowers total cost of ownership”:

My recommended progressions of configuration locations are as follows.  Specific requirements should be the driving factor that cause you to move configuration from one medium to the next costly alternative.

1. In the code
2. In a file
3. In a database
4. Some other system-specific external configuration store

I wanted to call out option #3, which is to put configuration information in the database. Over the years, I’ve heard numerous proposals for putting configuration information in the database. Nearly every proposal has a good counterargument.

Putting configuration information in the database is easier.

Easier than checking in code? If so, then you might have a problem with your source code repository. More often than not, “easier” means someone is trying to circumvent testing, check-in policies, revision control, or code reviews.These are all things you shouldn't avoid.

Our configuration information is very complicated.

Complexity isn’t something a database can fix. The configuration will still be complicated, and to make matters worse - it’s now in the database!

We need to access configuration values from everywhere.

If this is a highly distributed system, then this might be a good argument, but sometimes “everywhere” means “the business logic inside of stored procedures”. There is no reason to make it easier for business logic to sneak into the database.

The database should be one of your last choices as a repository for configuration information. Configuration in code is easily tested, versioned, changed, and refactored. As Jeff said – only a specific requirement should drive you to a more costly alternative like the database.