Storing Settings in SQLite Database vs Separately

The same question arises in most of the projects I work on. Usually, I do this:

1. If the set of possible values is unlikely to change any time soon, I use class/interface constants or enums in the code and enumerable fields in the database. Example: state of publishing of blog entries: 'not published', 'under moderation', 'published', etc.
2. Values will probably change, but changes will not affect program logic - config files. Example: list of "how did you find our website?" options for a dropdown list in online purchasing form.
3. Values are likely to change frequently and/or meant to be edited by non-developers, but yet these changes will not affect the logic - a database or at least a key-value storage with some user-friendly interface for editing.
4. Changing the values will affect the logic - probably the system needs redesign (often true) or some business rules engine is needed. The most difficult case I've seen so far was psychological tests constructor my colleague worked on. Each type of test may have its own scoring system which may vary from simple addition to multiple characteristics scales with positive and negative values or even human evaluation of answers. After some discussion about this project, we ended up using Lua as a scripting engine, which totally conflicts with the ability of non-developers to create new tests (even though Lua is a relatively simple language you shouldn't expect that a non-programmer will learn it).

About the quote from TPP. I think it's true for pristine code, but in real life, you better start simple (KISS principle) and add features later if they're really needed (YAGNI).

Given that your application needs that kind of complexity, then here are my 5 cents (I will use Java code):

Settings are split in two categories acording to whether or not they take immediate effect when they are altered.

• dynamic: have an immediate effect in the application's behavior
• static: don't have an immediate effect in the application's behavior and only take effect on application restart, or on config reload.

The scope of altering a setting can be:

• memory
• disk
• memory and disk

I think the Configuration object should implement this interface:

import java.util.List;
import java.util.Map;

public interface Configuration {
    // key is the name of a setting
    public void reload(); // reloads from disk without restarting app 
    public String getValue(String key); // gets value of setting identified by key
    public String getOldValue(String key); // gets old value of setting identified by key
    public String setValueToMemory(String key); // alters value of setting identified by 
                                                // key only in memory (will be lost after reload or restart)
    public String setValueToMemoryAndDisk(String key); //alters value of setting identified by key 
                                                       //both in memory and disk (will persist after reload or restart)
    public String isDirty(String key); // indicates whether or not this setting is "dirty", 
                                       // meaning it's value is different from disk.
    public Setting getSetting(String key); // return setting metadata
    public void dump(); // prints all key-value pairs
    public List<Setting> getSettings(); // gets a list of all settings (metadata)
    public Map<String,String> getValues(); // gets a map with key-value pairs 
}

In order for the Config Window to be able to visually indicate whether a setting is dynamic or static, a list of Setting objects should exist

public interface Setting {
    public String getName();
    public String setName(String name);
    public String getTag();
    public String setTag(String tag);
    public boolean isDynamic();
}