Configuration Persistance Design
I'd say it depends on how many parameters you have, and whether this list is expected to be largely static or if it's likely to change or expand.

I'm still a little fuzzy on exactly what you're doing, so I'm going to answer a slightly different question.  Let's say you're writing a query engine, searching for users that meet different requirements, and you want to store a set of predicates so it can be reused.  In a simple world, your table might look like this:

CREATE TABLE Searches
    (
    ID  INT NOT NULL PRIMARY KEY,
    CreatedBy   INT NOT NULL,  -- Prob also CreatedDate, LastModified, etc.
    FirstName   VARCHAR(100),
    LastName    VARCHAR(100),
    Sex CHAR(1),
    EMailAddress    VARCHAR(100),
    Country INT
    )


Some day you'll need to add a Region field when you start storing more precise geographic data.  Then you'll add PhoneNumber, and then BloodType, and then... eventually, you'll need something more flexible.  You need a table for searches and a table to store key-value pairs for each search:

CREATE TABLE Searches
    (
    ID  INT NOT NULL PRIMARY KEY,
    CreatedBy   INT NOT NULL
    )
CREATE TABLE SearchTerms
    (
    ID  INT NOT NULL PRIMARY KEY,
    SearchID    INT NOT NULL FOREIGN KEY REFERENCES Searches (ID),
    FieldName   VARCHAR(100) NOT NULL,
    Value   VARCHAR(100) NOT NULL,
    UNIQUE (SearchID, FieldName)
    )


The UNIQUE constraint may not be appropriate.  For example, it may be appropriate to have a search with Terms { FieldName = "FirstName", Value = "Bo%" } and { FieldName = "FirstName", Value = "ob%" }.

This more flexible approach loses type checking; searching for "NumArms = 2" now requires storing "2" in a VARCHAR field.  It also implies using dynamic SQL to construct your searches.