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.
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):
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