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

You can expand option 1 to have a 3rd column, giving a data-type. Your application can than use this data-type column to cast the value.

But yeah, I would go with option 1, if config files are not an option. Another advantage of option 1 is you can read it into a Dictionary object (or equivalent) for use in your application really easily.

Answer 2

My project uses a database table with four columns:

1. ID [pk]
2. Scope (default 'Application')
3. Setting
4. Value

Settings with a Scope of 'Application' are global settings, such as Maximum number of simultaneous users.

Each module has its own scope based; so our ResultsLoader and UserLoader have different scopes, but both have a Setting named 'inputPath'.

Defaults are either provided in the source code or are injected via our IoC container. If no value is injected or provided in the database, the default from the code is used (if one exists). Therefore, defaults are never stored in the database.

This works out quite well for us. Each time we backup the database we get a copy of the Configuration which is quite handy. The two are always in sync.

Answer 3

I use a mix of option 2 and XML columns in SQL server. You may also wan't to add a check constraint to keep the table at one row.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

Answer 4

I've used both 1 and 2 in the past, and I think they're both terrible solutions. I think Option 2 is better because it allows typing, but it's a lot more ugly than option 1. The biggest problem I have with either is versioning the config file. You can version SQL reasonably well using standard version control systems, but merging changes is usually problematic. Given an opportunity to do this "right", I'd probably create a bunch of tables, one for each type of configuration parameter (not necessarily for each parameter itself), thus getting the benefit of typing and the benefit of the key/value paradigm where appropriate. You can also implement more advanced structures this way, such as lists and hierarchies, which will then be directly queryable by the app instead of having to load the config and then transform it somehow in memory.

Answer 5

I vote for option 2. Easy to understand and maintain.

Answer 6

I use option 1.