Hello All!! I am ressurecting this thread to do some comments and ask for more suggestions.

So lets see the old messages...

--- In firebird-support@yahoogroups.com, "unordained" <unordained_00@...> wrote:
>
> ---------- Original Message -----------
> From: "emb_blaster" <EMB_Blaster@...>
> > Example
> >
> > CREATE TABLE CONFIG (
> > "SPLASH_SCREEN" BOOL,
--> > "DEFAULT_USER_NAME" VARCHAR(20),
--> > "ANOTHER_CONFIG_TAG" FLOAT,
--> > "YET_ANOTHER_CONFIG_TAG" INTEGER
> > .........
--> > "many_CONFIG_TAGs_later" SOMETYPE_OR_DOMAIN)
> >
> > OR
> >
> > CREATE TABLE CONFIG (
--> > "CONFIG_TAG_DESCRIPTION" VARCHAR(..) <--this is a PK
--> > "CONFIG_TAG_VALUE" VARCHAR(...))
> >
> > 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?

I Changed specifications of table to columns on example 1 have differents types of data as you all can see. Thats are one "plus" of example 1 as Philip said on message below...
Also changed example 2 column CONFIG_TAG_VALUE type to VARCHAR(xx) cause it should be the most generic way to store a tag value, and the way it was did seems that it would be of only one type.
And finally I added a PK on CONFIG_TAG_DESCRIPTION.

Now to Philip comments....

> ------- 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, ...]

I dont think that this workaround is a good way to solve. Maybe it get more confuse. So i changed it to varchar, and when we get that value we get it on varchar and then convert it to the desired type.

> + if referencing parameters elsewhere in database (stored procedures),
> dependency tracking makes sure you don't accidentally break the procedure
> [no workaround]

okay, this is realy plus of this one row solution. I think is the only one that theres no workaroud at all.

> + 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]

I don't know if i get this correctly, but besides we can make another table for this, I realy don't like this way. I think that one more table will get away from the intention of it seems simple, easy and pratice. Also, remembering that when u work with *.INI files you always (or at least almost always) know what type of thing you are expecting, I assume that this is also true to work with this CONFIG table.

> + 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]

Same of the comment above. Thinking on *.INI files, your soft should probably know of what was the defaults.

> + cannot accidentally insert two rows about same options
> [workaround: put a unique or primary key constraint on config_tag_description]

I added that!! So now theres a Primary Key on CONFIG_TAG_DESCRIPTION. :)

> - limit on row size, at least when selecting data (64kb -- still a lot!)

yeah!! that should be like more than 1000 field Varchar(60). So still a LOT for sure!!! O_O

> - adding new options means a change to metadata, not just data

or in others words, that means that adding a new parameter to your soft can make things like a pain, specialy if you dont wanna stop database of working... :║

> - no ability for multiple transactions to update different options concurrently
>
> -Philip
>

Yeah!! That last one (multiple transactions update) should be one really loss if the file to configuration is on a database on the server and not local one.

If anyone of you have ANY other comments to this subject, I will be really glad to know about.

Thanks for all comments.
kind regards,