---------- Original Message -----------
From: "emb_blaster" <EMB_Blaster@...>

> Example
>
> CREATE TABLE CONFIG (
> "SPLASH_SCREEN" BOOL,
> "DEFAULT_USER_NAME" BOOL,
> "ANOTHER_CONFIG_TAG" BOOL,
> "YET_ANOTHER_CONFIG_TAG" BOOL
> .........
> "many_CONFIG_TAGs_later" BOOL)
>
> OR
>
> CREATE TABLE CONFIG (
> "CONFIG_TAG_DESCRIPTION" VARCHAR(..)
> "CONFIG_TAG_VALUE" BOOL)
>
> I think that example 1 is more fast for a select, but example two
> are much more easy for mainteanence (that´s the word? sorry the english..)
> there´s a best choice in this case?

------- End of Original Message -------

+/- for one-row solution [with workarounds to get equivalent benefits from the
multi-row solution]:

+ each option can be a different, specific type (some bool, some varchar, etc.)
[workaround: config_tag_bool, config_tag_varchar, config_tag_int, ...]
+ if referencing parameters elsewhere in database (stored procedures),
dependency tracking makes sure you don't accidentally break the procedure
[no workaround]
+ list of possible options is available for anyone to see
[workaround: create a table of possible options (and their types?), and setup
a foreign-key relationship between the actual config and the possible config]
+ you can set defaults directly in the column definition
[workaround: a trigger to look at the config_tag_description and decide what
the default should be]
+ cannot accidentally insert two rows about same options
[workaround: put a unique or primary key constraint on config_tag_description]
- limit on row size, at least when selecting data (64kb -- still a lot!)
- adding new options means a change to metadata, not just data
- no ability for multiple transactions to update different options concurrently

-Philip