Re: Table design for application options

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:41c09ae5$0$78772$e4fe514c_at_news.xs4all.nl...
> Bugblatter wrote:
>
>> 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.
>
>> 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?
>
> 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.

Welcome back and I hope the business has slowed for the holiday season.

It isn't overkill to use a text file and delimit your parameters with xml tags in something referred to as an XML document. In this case I would suggest it is overkill to have an xsd or dtd file to correspond to an XML parameter document. Having the tags just makes it a tad bit easier to understand and less likely to make mistakes when maintaining the parameter data than if you used a comma-quote delimited file for the same purpose.

There are definitely ways to overkill with XML, just as there once was with JCL (there is some buried information about //DD in my brain somewhere). But a nice streamlined XML document sans xml schema file would be a modern and agile approach, I would think.

Cheers! --dawn Received on Wed Dec 15 2004 - 22:08:29 CET