survey

hi all,
sorry for the previous blank post...it was posted accidently...

I have to publish an online survey form which will target a global audience.
I want to incorporate dynamic analysis of the survey results...in other
words I should be able to interpret the feedback whenever necessary. The
form has been created using the Rails helper methods - I need tips on how to
analyse the database entries efficiently. Any alternate/ more efficient
solution would also be welcome.

Thanks,
Sandip

Quoting sandipfloyd <sandipfloyd@gmail.com>:

hi all,
sorry for the previous blank post...it was posted accidently...

I have to publish an online survey form which will target a global audience.
I want to incorporate dynamic analysis of the survey results...in other
words I should be able to interpret the feedback whenever necessary. The
form has been created using the Rails helper methods - I need tips on how to
analyse the database entries efficiently. Any alternate/ more efficient
solution would also be welcome.

Since no details of the kinds of analysis are provided, it is rather hard to
give specific advice. Since the data is in a database, any programming
language or statistical package with an interface/API to the database can do
something. You could do the analysis in Ruby, SQL, C/C++, etc. Whatever is
comfortable.

Jeffrey

How many surveys do you expect to be analyzing (absolute maximum) and
how many fields are there per survey? Also, what types of analysis
need to be done?

Reason I ask: Ruby is not designed for efficient execution, it's
designed for efficient development.

One tip I can give you straight off: don't use SQLite (default for
Rails 2), it's very inefficient especially when indexes are needed.
Use MySQL.

Another issue for efficiency in data analysis: Rails has no way to
specify types of indexes with add_index in migrations. add_index
simply uses whatever the default index is in that particular database
which is normally a hash -- good for unique lookups, bad for range
lookups. You'll need to set all indexes that require range lookups
manually in the database to tree indexes. (I am in the process of
creating and recommending a patch to add index type selection to the
add_index method)