if i design a survey has 500questions, the mysql table column is 500.
is it a problem of mysql database design?

Actually there will be a lot more columns, depending on the question type. For example, each subquestion of a multiple answer question type will have it's own column, etc.

Usually the limit of the database engine is around 1000 columns, but this depends a little on your installation.

is that the coding problem? my tech staff told me it's not a good database design.

I am not an expert, but for analysis purpose, I think it is the standard. Because one thing is to have the best database layout, but then you need to be able to export the results database. Some write all answers into one cell, which I find a very annoying habit and I think it is a lot better to have each answer it its own column.

As I said, I am not an expert. But if you tech staff has a genius idea for a better database design, I am quite sure that the developers will be happy to have a look at it...

But they need to keep in mind that the results database needs to be able to be exported to use them in programs like SPSS for analysis.

A 'better' database design is always a matter of taste.

The current database design is targetted at speed and easy readability. Other forms will be able to store more columns but will lack both speed and readybility.

TBH, not many people put 400 questions into their survey - and we try to cater to the mainstream user, not the extremists

And if you don't have many multiple choice questions and don't need timestamps, 500 questions should still fit, shouldn't they?

Yes, they should. Timestamps is not a issue. Multiple choice are.

But if you have the timestamps you add another column per question, don't you? Which means 500 questions will have 1000 columns, even if not multiple choice, or are the timestamps coming from a different database table?

Time stamps are held in a 2nd table - not in the responses table.

yes, my tech staff said if the the column is more than 500, best way is to split mysql table into 2 parts, it's better perfomance to read and insert.
i am not the mysql expert. i just think it's very common to creat a survey with more than 500 questions, because we have EM to jump to a question.
i also notice LS put all surveys questions into 1 table.i think it's better to put 1survey questions into 1 table.

One table one question? I don't think that makes much sense. You will bloat your database a lot.

And to be honest, I agree with Carsten, 500 questions is really a lot. I guess it is not for market research. Because from my experience, when the questionnaire gets too long, the last questions are actually not worth asking, because no one thinks about the question anymore, but just tries to click through. If they don't drop out.

Anyway. I agree that it would be a great addition if we could have a feature where Limesurvey could add a second table so that more questions can be included. When you have a lot of multipe response questions with a lot of answers, you get to the limit quite quickly.

Maybe you can make a feature request in the bug tracker?

holch wrote: Anyway. I agree that it would be a great addition if we could have a feature where Limesurvey could add a second table so that more questions can be included. When you have a lot of multipe response questions with a lot of answers, you get to the limit quite quickly.

Maybe you can make a feature request in the bug tracker?

We are aware of that problem and have tried to solve it in the past several times. BUT... this requires a major code rewrite and currently we do not have the resources for that.
We prefer to use our limited resources for several minor improvements instead of spending lots of time on a single feature only with the risk of leaving something unfinished at the end of developers leave or the like.

Anyway, this is on our list and maybe we participate at "Google Summer of Code" next year which would be an option for implementing such a major feature.

Until then you need to split up surveys and pass IDs to hidden questions to merge data later.
...or just don't annoy your users with hundreds of questions

> or just don't annoy your users with hundreds of questions

I agree. But often Limesurvey is used for things slightly different to what we know as market research, etc. Sometimes it is more a help for data entry, etc.

And with with 10 multipe choice question with 100 items the limit is also reached I guess.

I also agree that this is not the most important feature for sure. If it is so hard to implement, we should focus on other things instead to "waste" all forces on this feature, which I would call "nice to have".

Thank you for the further explanation. Makes things a lot clearer.

But often Limesurvey is used for things slightly different to what we know as market research, etc. Sometimes it is more a help for data entry, etc.

Yes, and I'm pretty sure that LS will fit, more and more, a lot of those needs.... however my opinion is that people using the software in very special or extreme conditions have to adapt the code themselves; Open-source projects are made for this!

About surveys with +500 questions, I think the most important issue is not the software, but the ability of the coder to configure a very complicated survey using the excel import feature (hard to use LS GUI for this). Personally (and for the moment) I just can rely on one (found here ) :

"The EM author used similar view (a little cleaner) to let his collaborating Epidemiologists and Institutional Review Board validate and authorize surveys with thousands of questions in highly branched and tailored structured interviews"

i try to submit the bugtracker, but get 404 error.
1.it's common to disign a survey of more than 1000 questions. i am not aware of this question till the server speed become slow, then i notice LS mysql database design problem.i think sql database is the base of ls.
2.i am not sql expert. i review the sql database design principle guide just now, it's not recommended to put irrelevant things in 1 table, like all surveys questions.
3.i am not sure what's reason if put much column in 1 table, I/O?