Table design for application options
From: Bugblatter <nospam_at_spambucket.foo>
Date: Wed, 15 Dec 2004 09:38:59 +0000 (UTC)
Message-ID: <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?
Date: Wed, 15 Dec 2004 09:38:59 +0000 (UTC)
Message-ID: <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? Received on Wed Dec 15 2004 - 10:38:59 CET