Re: Table design for application options

"Bugblatter" <nospam_at_spambucket.foo> wrote in message news:cpp0ni$mef$1_at_titan.btinternet.com...
> If I have an application that has a handful of configuration options, what
> is a good way to store these options in a table?
>
> e.g.
> feature_x_enabled boolean
> default_currency_symbol character
> default_currency_name string
>
> and so on
>
> The obvious way, to me, is a table with one row with a column for each
> option. However this table would need to be redefined every time an option
> is added - making deployment of updates more complex. It also seems a bit
> strange to design a table that will only ever hold one row.
>
> I'm not sure whether it might be better to have a table with two columns:
> option_name and option_value. The latter could be a string value and would
> then have to be converted to/from other datatypes as appropriate. I'm not
> sure Codd would approve :-)
>
> What type of table structure do other apps use for this type of info?

Because I always use loosely-typed and non-1NF structures for application parameters, I would suggest that provides excellent flexibility that is very desirable for parameters. You might consider storing parms in an XML document that you read in, rather than in your database. I can just hear the groans in the audience, but the risk is low and the advantages are high.

Alternately, the key-data approach with every attribute defined to the RDBMS as a string and then cast to whatever other type is needs to be in the app as needed would also be OK in my opinion.

--dawn Received on Wed Dec 15 2004 - 16:48:58 CET