App Configuration and Databases

Monday, January 12, 2009

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.


Comments
Elijah Manor Monday, January 12, 2009
We tend to put a lot of configuration in the web.config of our UI or app.config of our MT (mainly because it's easier), but that tends to be problematic when we need to change a configuration during business hours since it bounces the app_domain in IIS.

We do have some configurations in the database, which does allow us to change settings mid-day if necessary without kicking off user's session mid-stream.
TweeZz Monday, January 12, 2009
Hi Scott,

One of our applications has a huge amount of setupable parameters (is that the same as 'configuration'?). Each one of them can be different for each customer. Each one of them can be of a different type (boolean, string, xml).
Would that be a reason to store configuration information in database?

Manu.
(manu.temmermanuyttenbroeck_at_gmail.com)
Frank Booth Monday, January 12, 2009
In my experience, I've really only seen config in a database at shops that have very restrictive, yet brain dead change control policies such that changing a configuration parameter in a config file requires a full change control process, while changing a value in a config table doesn't, because change control covers production files, but not data.

scott Monday, January 12, 2009
@TweeZz:

It sounds like you might have a case for config in the database. Does the customer enter these values in a setup procedure?
Marc Monday, January 12, 2009
We're a small ISV working with a large corporation ("dancing with the giant") - they have *3* releases per year, and we don't have access to the web server and their file system --> thus, the only valid choice for us is to put *as much configuration as possible* into the database, since that can be tweaked and adapted when needed, without having to wait for 3-4 months (in the worst case).

It also seems to make it a lot easier for us to deal with DEV, TEST, STAGE and PROD environments - no more installing the wrong web.config into your app... :-)
Dennis Gorelik Tuesday, January 13, 2009
I agree -- the default choice should be to put configuration right in the code that uses that configuration.
Putting configuration into database is a popular anti-pattern.
If configuration is in the code, it's easier to deal with DEV, TEST, STAGE and PROD environments.
Web config makes it harder. Database makes it even harder, because it's harder to control configuration versions in the database.

Release cycles of 3-4+ months indicate some problems with development culture in the organization.
bignose Tuesday, January 13, 2009
> There is no reason to make it easier for business logic to sneak into the database.

You think business logic should be somewhere else? Where, and why would that be better than in the database?
scott Tuesday, January 13, 2009
@bignose:

I think logic in the database is harder to write, harder to read, harder to change, harder to refactor, harder to test, harder to version, harder to debug, and harder to scale. T-SQL and PL/SQL might be turing complete languages, but I think they pale in comparison to most other general purpose programming languages for the expression of business logic and algorithms, and the tools for these other languages are better, too.
TweeZz Tuesday, January 13, 2009
Hi Scott,

It's not the customer which enters these parameters, but a few people working in our company. They use a stand alone application to do so.
Rick Strahl Tuesday, January 13, 2009
Agreed. Putting configuration info into the database is fraught with problems. One of them being that typically one of the configuration items is that database connection string? :-} So typically you can't completely get away from a config file or code store or something.

My preferred approach is to use a strongly typed class that persists and reads configuration content from one of many supported stores. This way the configuration is strongly defined and you can choose (based on code options) how and where to store it (including a database although I tend to avoid that).
Eber Irigoyen Wednesday, January 14, 2009
I have an app where the configuration takes about 60 database tables (there are dependencies between them), that falls in the "Our configuration information is very complicated."

how would you store such configuration in any other way, without making the solution even more complex?
scott Wednesday, January 14, 2009
@Eber:

Depending on the scenario, I might use a class for each table that you currently have. You can have intellisense, refactoring, and compile time checks if you use the classes to create your config - not so in the database unless you write a custom UI and validator.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!