Re: Table design for application options
Date: Wed, 15 Dec 2004 21:15:28 +0100
> If I have an application that has a handful of configuration options,
> what is a good way to store these options in a table?
Strictly: A table is a way to *represent* data.
Not a way to *store* them.
Files, filesystems serve to actually store stuff. Surely this is nitpicking and everybody talks like this, and thinks along the lines of storing data in tables. SQL reinforces this way of thinking. We think of storing data in tables so we don't have to worry about how the data is really stored.
> 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?
Why store these data in table-form?
They do not strike me as very tabular.
Are they application-wide configuration options?
Some form of textfile will do.
This is a often recurring problem. Your operating environment and your team will have some accepted conventions for this. In unix, tradionally .rc files are used, windows moved from .INI files to registry-entries. The current overkill approach is: use XML. Received on Wed Dec 15 2004 - 21:15:28 CET