Xml vs. Database for application configuration

Question

My application configuration is very hierarchical and fits nicely into a single XML. Soon (YAGNI, Yeh) parts of this information will be consumed by other applications remotely, which calls for a database.

So, I went into designing DB tables and mapping them back to my application's class hierarchy (using EF). however it became a maintenance nightmare.

I'd love to hear from others experience considering this issue, thanks.

Answer 1

IMHO config should live in files, files work well for people and they're ok for computers. DBs work well for big data, but they're overkill for human stuff. The two are normally mutually exclusive, and when you do try to combine them you get something like the registry - uggh.

Why not leave the config in a file, and build a DAL and service layer around it so that your apps can use it. That assumes you can host onto a central server, if not have multiple copies of the file in the wild.

Answer 2

Using a database (maybe to store this config xml file, if you wish to retain the format) has advantages - you can log/audit changes to the configuration and also do backup and recovery.

Basically your question (the way I see it) mixes two things,

1. What format the config should be in (xml, .ini file, etc)
2. Where it should be stored (flat file on disk, table column in database)

You could easily store the config xml file in a database and provide an interface for editing/displaying the info.

Answer 3

Config files should be the most easiest things to handle - so put them into files. This way someone can make changes there even with notepad (if necessary). Database is really an overkill, unless you want your configuration reside in some global server and all instances to share it.

Answer 4

We had very good experience with storing the config in a database for long running applications (like web sites and services). Advantages:

• You can edit the config remotely and securely (user/password)
• It is simple for the application to pick up changes (select max(lmod) from config) automatically or by a signal (ping a web page or create an empty file somewhere)
• The application only needs a single item of configuration per environment (dev, test, prod): The DB to use. If you have an application server, your applications are config free for all environments.

The main problem is the editing if you have a complex, hierarchical config structure with defaults, lists and inheritance. Our solutions:

• The config table has these rows: Application varchar(32), Key varchar(512), Value varchar(4096)
• One DB per environment (local developer machine, development test, integration test, production)
• The key is hierarchical (option.suboption....name)
• Defaults use "option..name" (for example, "jdbc..driver" since we use only one type of database)
• Lists are stored as strings, separated by newline.
• Maps are stores as strings, "name=value\n"
• There is an implementation which can read the config from a file (for unit tests). Map each hierarchy of the key to an element (......)

Config objects hide these details, so the application just works with objects.

A special class is responsible for re-reading the config in case of a change. Usually, we update the config some time during the day and a timed job will reload it after hours. This way, we never need to synchronize the config methods.

Backup and change history were a problem, though. We fixed that by using XML files in the VCS which are then "uploaded" to the DB. This way, we could verify the production config before uploading it (by using it with a special set of unit tests on a developer machine). When it got activated during the night, it usually worked right away and the operator responsible for the app would just have to do a little bit of testing.