Re: Table design for application options

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Wed, 15 Dec 2004 09:48:58 -0600
Message-ID: <cppmdg$r4n$>

"Bugblatter" <> wrote in message news:cpp0ni$mef$
> 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

Original text of this message