Re: [phpesp-dev] Respondent database

[James E. F. <jf...@ac...>]

[ Please try to make your email wrap at something slightly
less than 80 characters, thanks. ]

A few points here. Having the data fields associated with
each respondent be arbitrarily chosen by the designer is
difficult. Databases are designed to, and work best when,
the fields are pre-determined. Adding a new table per
survey to store this information is a bad idea for several
reasons. The other option is to somehow store the data in
one (or two) predefined tables -- this is sort of how the
survey questions work, its dirty and slow.

Having a way to add respondents in bulk is certainly a good
idea. I agree that an option to import them from either
text (csv or xml) would be helpful.

When you are analyzing the data, it should be very easy to
include the rest of your respondent information. One of the
great thing about relational databases is that you can join
tables. Simple use one of the phpESP fields (username,
email, etc) as a key into your separate database with all
your custom data.

I am constantly amazed by people wanting to take the data
out of a database and put it in excel. To me it seems that
in doing so, you give up so many tools available in SQL. Oh
well, I suppose it's because excel is pointy-clicky, and to
take full advantage of a database requires substantial
knowledge of SQL. It is certainly well worth learning if
you need to do any substantial data analysis. There are
also several tools to help you with this, I know that SAS
can use an ODBC database directly as a data source.

(More at a later date on quota management.)

-James

On Sat, 22 Jun 2002, Creative Minds wrote:

> Hi There,
>
> I see a lack of functionality in the respondent
> database. First of all, normally when you conduct a
> study you would not add respondents one by one but
> rather want to upload an entire set of respondents. May
> I recommend using a non-predefined format for this.
> Respondent information can be very different from
> survey to survey.
>
> I think you should focus on a Comma Separated file for
> upload with first line containing variable name. After
> that a guide (as in Excel for instance) where you
> define what kind of variable is in the field.
>
> This would be a good next phase in development before
> we head on to quota management etc. Because if have a
> survey where you need 500 males and 500 females, you
> should be able to create a field inside the survey
> which then stores values to the respondent database and
> not just to a datafile. And inside the questionnaire
> you should be able to check whether you have or do not
> have enough respondents of a certain quota group and
> make a condition to end the survey for that respondent
> with the motivation that the quota group is full.
>
> Any opinions?