I’m building an application which uses SQLite, and now want to add settings that are stored between sessions
I’m considering if I’m going to store the settings in a config file or if I’m going to use a table in the database for this
(Please note that I’m using SQLite which stores data locally and doesn’t have a user accounts)
The reason I’m thinking of using the database is that I’d like to avoid adding more complexity and since I have already set up my SQLite database I’m thinking that I might as well use it for settings as well
What do I need to consider when choosing between these two options?
I’m leaning towards using a table in the database but am a bit worried because this answer says that storing settings inside the database is a bad separation of concerns.
However I’m not sure what practical drawbacks there would be. In terms of the code being self-documenting and in terms of readability it’s clear where the settings are if the db table is just called “settings”
(One drawback I can think of might be if I expect the settings to change much more quickly than the db schema, since that would mean changing the database which is more complicated than changing the settings)
Grateful for help with this!
Similar questions:
- Should I use a config file or database for storing business rules? — similar to my question but more specific (about storing business rules). I would like to know about what general considerations to make when choosing between the different options
- How are typical settings stored in a program?
7
The largish legacy application I maintain has gone back and forth on this over the years, but has evolved towards keeping most settings in the DB. Yes, the DB connection string is read from the config file. This is a desktop application that heavily uses a DB and which has quite a few settings. If you have very few this will be less applicable, but these are the first reasons that come to mind:
-
Config files are typically read only on startup, changes mean restarting the application. (Not a hard rule, but intended use.)
-
Settings from the DB can be edited via a GUI that is part of the application and directly updated using the already existing DB routines without needing to access some external file.
-
Changes made by the GUI can easily be used to raise events and the new values can be used immediately. You really don’t want to be monitoring changes to an external file – see first bullet.
-
The DB is not accessible to regular users and changes there can be restricted and validated. A config file is exposed and can be changed with any editor, with no validation of values.
-
We have sets of settings – “Profiles” – that are customized on a per-installation basis. This would be somewhat cumbersome to maintain with a config file.
3
I don’t agree that storing settings in a database table is a bad separation of concerns. Your “concerns” will be separated by not defining a relationship between the settings table and other tables in your database. This is fine.
The main thing to consider is how you expect the administrator of your system to make changes to the settings. It’s much easier for most people to just open a configuration file and make changes. If you store your configuration in a database, you’ll have to give access to users/admins to make changes. If they’re not comfortable making changes directly in the database, you may have to provide a screen in your application for making those changes. I’ve done this in both web and mobile applications and it works fine. (Since the changes are made through the application itself, it even bypasses the need to restart the application like you would if changes were made externally by editing a file.)
2
It all depends on how big your settings are. If it was a couple of values, then it would be simpler and less overhead to store it in a file. Especially that this file could be an XML that is easy to handle.
If you need to store your settings somewhere safe (e.g. saving credentials), then a database would be a slightly better option. Of course you should encrypt those credentials when you either save them on a file or in a table.
From an architectural point of view, you should save at least one piece of information in a file, i.e. your database connection string, so that you would not hard code it (bad practice).
5