Application configuration in the database

Recently K. Scott Allen posted an article called App Configuration and Databases.

His conclusion is:

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.

I humbly disagree. We used to put are configuration into the web.config or our projects. This was easy, but had two down sides:

1. Whenever we release a new version it’s best our operations guys overwrite to old config, because we might have changed some values in there that they should not mess with. Things like configuration for our DI containers, or WCF settings. They do need to copy the settings from the old config into the new one and that takes time and there is chance of error, especially if you have large config files.
2. It’s impossible to do “hot-configuration”. If you change the web.config, IIS will restart the web application. This is not a big issue, but did cause some problems once or twice.

As for configuration in code I see the following problems:

1. We use OTAP (separate environments for Development, Test, User Acceptance and Production), this mean that we’d either have to create different “configuration DLLs” for our different environments or that we’d need to have code that detected what kind of environment the application ran in and use that to determine the correct configuration.
2. If you’d need a configuration change, you’d need a developer to check-out code, change it, check it back in and deliver the code to test. Test would need to run al kinds of tests and when all done deliver the application to operations for installation. Configuration in a separate file, or database is something the operations guy can do himself.
3. We, as developers, don’t have access to production machines. Security regulations dictate we should not know passwords to production environments, so we couldn’t even create the configuration DLLs.

Of course these concerns can all be addressed, but we decided it was better to use a database.

• If the configuration is in a database, the application (and it’s associated web.config file) can be overwritten without problems. (Of course some values would need to be copied, but they would only be a few).
• We can provide the application with default configuration values and the tester can change them for the test environment. The guy from operations can change them into the production values.
• If you’re doing load balancing on the application it’s possible to reuse the same configuration database (might not be practical for some systems, but it is a possibility).
• It’s easy to add a configuration page to an administration web application that we’ll probably need to build anyway.

So all-in-all it seems like the best solution for us (for the moment), but that’s largely because of the way we work. Your company may use other methods which might not make configuration in the database the best choice, but I don’t think it should be the last choice.