Config versus Database

I was thinking a little about the pros and cons of storing configuration data in config files versus using a database. I have to tell you, that for all of the learning and work I did for POP Forums (like two years ago!) seemed pretty slick at the time, but now I'm not so sure that using config files is the way to go for most things.

I guess the change of heart came around because back in the day, and by that I mean the ASP.old days, we didn't have caching, and I had no idea what a static anything was. Sure, I stored stuff in the application object (*shudder*), but I still didn't really think the way I do now.

Config pros:

  • Simple text changes change config
  • Notepad r0X0rz teh big one!!!!1111

Config cons:

  • If you don't externalize the file from web.config, your app restarts on changes
  • Simple config sections suck for large blocks of text (like TOS or e-mail templates)
  • Who wants to wade through text files and not UI? (yeah, I know you can programmatically alter them)

Database pros:

  • Cache your junk
  • Big giant text field capable

Database cons:

  • Not as trendy as .NET config files
  • Potentially big load on app start (though I don't know it's worse than config files)

 I guess in the end it doesn't matter, but what's starting to concern me is that the more crap you have in config files, the harder they are to manage. We already have to put all of our HttpModules and HttpHandlers there, Atlas adds a huge ton of crap, sometimes you still need those lame AppSettings things, etc. It's just so non-tidy.

6 Comments

  • I tend to like the database solution, mostly because my company is product-based with many customers. Having our customers make backups of .config files before uninstalling and reinstalling new versions can be painful, especially if the backups aren't done.

    With the settings stored in the database, this isn't a problem.

  • An application I worked on previously had everything in configuration files - and not just one config file but dozens, and they were hierarchical with overriden sections and all sorts of nastyness.

    I hate that project.

    I HATE THAT PROJECT.

    ARRGGG THE DAYMARES ARE STARTING AGAIN ARRGGGG.

    (Use the database for configurations!)

  • Writing the config files is only half the battle and the easiest part at that. Imagine deploying an app that has critical data in the web.config. In later versions of the app you may have new config sections and deprecated config sections. Merging the applications changes into the users current config files will drive users crazy. DotNetNuke has had this problem since very early on. We tried to move all settings to the database, but the more we used features from Microsoft, the more we were forced to bloat the config file. In my mind, the web.config has become the new registry, only now my main UI is notepad.

  • I tend to use both. Web.config with has the initial DB connection string and some simple settings.

    Once this get more complicated I like it in the DB. When I am deploying to remote servers it's easier to update setttings through query analyzer than navigate folders and be a notepad jockey.

  • Personally I like the database option best. I've also seen some companies use the system.configuration block or, the now deprecated, Logging Application Block to write configuration information that can be redirected by the user to either the database or the config file as needed or any number of other sources. It's pretty slick, but IMHO overkill.

  • Today, after lots of struggling with Config Files, I finnaly wrote the famous words ".Net Config Files suck" in my Google search bar, and ended up here. Why in heavens name would I want to deploy my development config file with my development settings to a user. When I deploy a application using click-once (smart client) It keeps deploying my config files in new folders, and therefor "changing" the settings of my end-user. I cannot expect my end user to keep changing the config file every time an update is done. If my end user succeeds in FINDing the darn file, he doesn't have (and want to have) enough XML knowledge to change the file. Isn't there another (easy) way to store user settings?

Comments have been disabled for this content.