Question: 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](https://softwareengineering.stackexchange.com/a/179577/196326) 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?](https://softwareengineering.stackexchange.com/questions/179572/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?](https://softwareengineering.stackexchange.com/questions/334877/how-are-typical-settings-stored-in-a-program)

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