From: Thew, Robert <rthew@mi...> - 2007-09-12 15:11:29
I agree that we should be able to get good performance for users taking
the surveys, regardless of the schema used. The problem will come when
doing analysis and reports. There may be another way to approach this
problem, by changing the way users get results from the survey.
Have you ever seen the Many Eyes
(http://services.alphaworks.ibm.com/manyeyes/app) site? The site lets
users upload Data Sets that can then be visualized in many different
Think of LimeSurvey as being a producer of Data Sets. These Data Sets
can be created from the results of one survey, or could span multiple
surveys. They are generated and then visualized using a service like
Many Eyes, or with a simple reporting tool that's a part of LimeSurvey.
The important thing is that whatever tool is used to visualize the Data
Set, the tool never directly queries the database. It consumes the
generated Data Set. This removes the burden of database performance
from the visualization tool.
The generation of the Data Set would be handled by LimeSurvey. The user
would never query the database directly. As part of the survey design
process, they could design one or more Data Sets they want as output.
These Data Sets could be scheduled to be produced periodically, or
after all the Reponses are complete.
Because the user is never going to be in a situation where they click a
button in the browser, and then have to wait while the database is
queried before a report is displayed, the expectation of lightning-fast
database performance is removed.
We only need the app to be able to store and retrieve individual survey
Reponses quickly. The database should be designed to do this in the
simplest, most flexible way.
Get latest updates about Open Source Projects, Conferences and News.