How do you structure config data in a database?

Question

What is people\'s prefered method of storing application configuration data in a database. From having done this in the past myself, I\'ve utilised two ways of doing it.

Answer 1

Since configuration typically can be stored in a text file, the string data type should be more than enough to store the configuration values. If you're using a managed language, it's the code that knows what the data type should be, not the database.

More importantly, consider these things with configuration:

• Hierarchy: Obviously, configuration will benefit from a hierarchy
• Versioning: Consider the benefit of being able to roll back to the configuration that was in effect at a certain date.
• Distribution: Some time, it might be nice to be able to cluster an application. Some properties should probably be local to each node in a cluster.
• Documentation: Depending on if you have a web tool or something, it is probably nice to store the documentation about a property close to the code that uses it. (Code annotations is very nice for this.)
• Notification: How is the code going to know that a change has been made somewhere in the configuration repository?

Personally, i like an inverted way of handling configuration, where the configuration properties is injected into the modules which don't know where the values came from. This way, the configuration management system can be very complex or very simple depending on your (current) needs.

Answer 2

I guess this is more of a poll, so I'll say the column approach (option 2). However it will depend on how often your config changes, how dynamic it is, and how much data there is, etc.

I'd certainly use this approach for user configurations / preferences, etc.

Answer 3

I can think of at least two more ways:

(a) Create a table with key, string-value, date-value, int-value, real-value columns. Leave unused types NULL.

(b) Use a serialization format like XML, YAML or JSON and store it all in a blob.

Answer 4

Option 1 is good for an easily expandable, central storage location. In addition to some of the great column suggestions by folks like RB, Hugo, and elliott, you might also consider:

Include a Global/User setting flag with a user field or even a user/machine field (for machine-specific UI type settings).

Those can, of course, be stored in a local file, but since you are using the database anyway, that makes these available for aliasing a user when debugging - which can be important if the bug is setting related. It also allows an admin to manage setings when necessary.

Answer 5

Where do you you store the configuration settings your app needs to connect to the database?

Why not store the other config info there too?

Answer 6

I'd go with option 1, unless the number of config options were VERY small (seven or less)