Hi Tom,

Minor normalization issue with the survey_admin as a VARCHAR. I'm
assuming this person should be a user in the system and can be
represented by ID?

I agree. It should be foreign key to "users" table. (prefix_users.user_id  in current scheme).


As a feature request, I'd like to look at extending the attribute system
to allow for a whole bunch of abitrary meta-data to be associated with a
survey. With the way we use PHPSurveyour we have information relating to
each instance of a survey that we have to store in a separate table.
Ultimately I'd like to be able to branch within a survey based on
supplied meta-data (e.g. only ask question if attribute 'Gender' is

Again, I confirm this. Right now I'm making the additional custom table to contain this metadata.
I suppose it can be TEXT (to contain plain text or XML).


Re field names, I'm a big fan of human readable field names. I take your
point GreIf we want to shorten them I'd question why we need to prepend
the table name on each field. The fields exist in a 'namespace' (ie. the
table) that suitably qualifies each one. If there issues of ambiguity
then we need to make sure reference the table in SQL. And if we're
talking objects, questiontemplate.name makes more sense to me that
questiontemplate.questiontemplate_name .

The matter is we don't use *dot syntax* for simple queries like "select user_id from users...".
But you're right again, it can be a way to go.