Data base tables design questions for: user saved forms, user parameters

Hello,

I need some comments or advices regarding different tables designs
approach, for two part of our needs.

_*User saved forms*_
in our project, we want to give to our users ability to save form fields
values for later use. It will be named the fast OR saved searches. The
user can save more than one fast-search per search-form, for that he can
name it accordingly to the search characteristics.

We have a relatively huge number of search forms, each one with specific
fields. So I don't want, if possible, to use a distinct table for each
form.

The good and logic way to design the table for this purpose looks like :
SAVED_USERS_FORMS (
USER_ID INTEGER, -- corresponding user
FORM_ID INTEGER, -- system wide unique form
identificator (maybe varchar2 code rather than number?)
SAVED_FORM_NAME VARCHAR, -- name of the shorcut/saved
form, by user
SAVED_FIELDS_VALUES_PAIRS ???????, -- saved fields
key/values for PK (user, form, name) combination

PRIMARY KEY (USER_ID, FORM_ID, SAVED_NAME)
);

The hesitation here is : how to store the fields & values pairs, in
FIELDS_VALUES?
- XML field?
- our custom text structure and formating representing something key =>
value
- our custom serialized Java object into a field

OR

I think that the EAV kind of modelling technique can be a flexible way
to achieve our goal, but as I read on the net there's an important set
of downsides with this approach. But, this way, my table is something like:

SAVED_USERS_FORMS (
USER_ID INTEGER,
FORM_ID INTEGER,
SAVED_FORM_NAME VARCHAR,
FIELD_NAME VARCHAR,
SAVED_FIELD_VALUE ????, -- saved field values for PK (user, form,
name, field name) combination

PRIMARY KEY (USER_ID, FORM_ID, SAVED_NAME, FIELD_NAME)
);

So the new problem can be the field SAVED_FIELD_VALUE type enforcement.
Do we need to have a field for each data type, so validation complexity
can increase dramatically...

Do we need or is suggested to have in a way or another meta data tables
describing supported form fields, data types, etc?

Other things to take into account:
* simple and scalable solution, heh, ye, please.
* what happens if the form evolve over time? the final solution must not
crash or cause some kind of inconsistencies.
* ..... others ..... ?

To enforce SAVED_USERS_FORM to follow defined forms fields, upon
adding/delete one or more fields, consistency can be achieved by simple
meta data tables describing forms and associated fields. So the design
will look:

SEARCH_FORMS (
FORM_ID,
...
PRIMARY KEY (FORM_ID)
);

SEARCH_FORM_FIELDS (
FORM_ID,
FIELD_NAME ,
...
PRIMARY KEY (FORM_ID, FIELD_NAME)
);

SAVED_USERS_FORMS (
USER_ID,
FORM_ID,
SAVED_FORM_NAME,
FIELD_NAME,
SAVED_FIELD_VALUE,
...
PRIMARY KEY (USER_ID, FORM_ID, SAVED_NAME, FIELD_NAME)
);

but, this EAV approach isn't perfect because the value field must be a
varchar field that we'll possibly store dates, numbers, ....

What is the perfect solution?

_*User parameters
*_Same kind of problem for storing user system parameters... Is it
better to go with one table, 1 row per user with 1 collumn per parameter
like:

USER_PARAMS (
USER_ID,
PARAM1 ,
PARAM2,
....
PK (USER_ID)
);

this way, we can easily enforce the data types per parameters...

Or a more flexible approach with a table like:
USER_PARAMS (
USER_ID,
PARAM_ID,
PARAM_VALUE -- FLEXIBLE TYPE? VARCHAR?

PK (USER_ID, PARAM_ID)
);

USER_PARAMS (
USER_ID,
PARAM_ID,
PARAM_VALUE_INTEGER INTEGER,
PARAM_VALUE_VACHAR VARCHAR(4000),
PARAM_VALUE_DATE DATE,
...

PK (USER_ID, PARAM_ID)
);

like many modellers, it's easy to fall into the generic models easy to
maintain but harder to optimize and to ensure consistency? do we need a
kind of api for manipulating the parameters, enforcing types, etc....?
_*
*_thanks for any help or comments
Bruno