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)