<< Dates and Times - Software's Bane | Home | Astonishment Principles and Framework Behavior >>

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.

Print | posted @ Monday, January 12, 2009 3:59 AM

Comments on this entry:

Gravatar # re: App Configuration and Databases
by Elijah Manor at 1/12/2009 5:29 AM
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.
  
Gravatar # re: App Configuration and Databases
by TweeZz at 1/12/2009 5:50 AM
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)
  
Gravatar # re: App Configuration and Databases
by Frank Booth at 1/12/2009 2:00 PM
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.

  
Gravatar # re: App Configuration and Databases
by scott at 1/12/2009 3:48 PM
@TweeZz:

It sounds like you might have a case for config in the database. Does the customer enter these values in a setup procedure?
  
Gravatar # re: App Configuration and Databases
by Marc at 1/12/2009 9:58 PM
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... :-)
  
Gravatar # re: App Configuration and Databases
by Dennis Gorelik at 1/13/2009 1:28 AM
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.
  
Gravatar # Business logic; where should it go?
by bignose at 1/13/2009 4:16 AM
> 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?
  
Gravatar # re: App Configuration and Databases
by scott at 1/13/2009 4:58 AM
@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.
  
Gravatar # re: App Configuration and Databases
by TweeZz at 1/13/2009 6:52 AM
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.
  
Gravatar # re: App Configuration and Databases
by Rick Strahl at 1/13/2009 6:05 PM
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).
  
Gravatar # re: App Configuration and Databases
by Eber Irigoyen at 1/14/2009 9:35 PM
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?
  
Gravatar # re: App Configuration and Databases
by scott at 1/14/2009 10:54 PM
@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 have been closed on this topic.
Scott Allen
Posts - 869
Comments - 4493
Stories - 14