Use ini/appconfig file or sql server file to store user config?

Question

I know that the preference for INI or appconfig XML is their human readability.

Let's say user preferences stored for my app are hierarchical and numbers about a thousand items and it would be really confusing for a user to edit an INI to change things anyway.

I have always been using a combination of INI with appconfig.

I am leaning towards using sql server db file, now. Every time the user changes a preference while using the app, it would be stored into the db file - that's my line of thought. I am also thinking that such a config db file could move around with the app too, just like an INI.

Before I do that, any advice
1. If there are any disadvantages against using a db file over INI or appconfig.
2. If a shop uses mysql or oracle, do you think your colleagues would lift up their pro-mysql or pro-oracle eyebrow questioning why you would use sql server technology in a mysql or oracle shop? I mean, I am just using it like an INI file or app.config anyway, right?

Additional Info:
I hope people reading my question understand that I am not using an "enterprise database" but a "preferences.mdf" stored with the application. In that I am hoping to use ado.net to store user config items as entities.

Answer 1

I often store user preferences in a centralised database, as this means a user's setting can 'roam' from PC to PC.

Another plus is that user preferences are being backed up.

Answer 2

It really depends on the architecture of your application.

For example, if you're creating a web app, then you'll want to store the user settings in the database since the whole user/role system would be stored in the database anyway.

If it's just a simple desktop application used on individual machines with no interaction between the copies of the software, then you could use an XML file to store settings -- using a database might be overkill, especially if you're not using a database for anything else.

There are advantages and disadvantages to both methods, of course. If you use a database, that means there's a lot more setup steps involved in deployment (again, dependent on your architecture), while using a simple config file is more lightweight and can be moved around easily.

One thing to note: if you go the database route, you will need to use a config file anyway to store the information needed to connect to the database.

Answer 3

My general approach is to put user configuration entries in to a database (centralised in our case, but equally applicable as a local store).

However, there are exceptions to this and I store the following in a text-based file (app.config usually):

1. Details of how to connect to the database (I prefer to have this in the config file, rather than use a convention).
2. Any setting that could potentially stop the application from starting correctly.

If there are settings that could 'break' the startup, the user should be able to access them without using the software -- at a text-based storage is best.

In code, I write a single configuration class that 'knows' whether a configuration entry is stored in the text file, or in the database; this allows me to move a configuration from one to the other without breaking all references to it.

Herbie