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