In fairness, (and agreement with marto) you do not look to have put much effort in so far. You need to look into books or web sites which show good database design. No one in their right mind would create a table with 600 columns, one per answer.

As a start, think of the data you need to store and divide it up into relational tables. e.g., a table users storing a username and id, one storing questions and question id, one storing all possible answers and answer ids, and one answers storing user ids, question ids and answer ids. You have the state of answered questions for a user at any time by looking into the rows written into the answers table.

However there are many possible ways of doing this as your research will lead you to find.

You've not told us anything you've tried so far, this reads like a poor specification for something you've been asked to do for work/homework. This site isn't a code writing service.

Suggestions for places to start:

• Ovid's CGI Course from CGI Programming in the tutorials section.
• HTML::Template Tutorial from Framework, Templating, and Content Management Systems in the tutorials section.
• The fine art of database programming from Database Programming in the tutorials section.
• And potentially Installing Modules, should you need any help with that.

"As it will be web based script I'll be using MySQL DB. "

Note that other open source database platforms are avaiable :)

If you have any specific questions show us the code you have and the error messages you experience. See How do I post a question effectively?.

Martin

I think you did not get the point

I am not looking for someone to write a code for me, I am asking a question about the proper table structure that suits storing 600 answers / per user

Should I use 600 column table, or You've got some other idea ?

the other question was about the look-and-feel of the questionnaire ... answering 600 questions is sort-off boring and my solution was to use "save-state" so you don't have to answer all the questions in 1 day, is this the only solution or you have something else that works better??

I am looking for ideas not for codes and I showed you my effort

I am open to suggestions

Obviously a 600 column table is inappropriate, because tomorrow it will be 601.
Sounds like about three tables with just a few columns each.

user table
    user_id
    user_name, other login details
    (index user_id)

question table
    question_id
    question
    answer
    (index question_id)

answer table
    user_id
    question_id
    answer
    (index user_id+question_id)
[download]

If you have no further requirements, then it doesn't really matter how you store it. Until you know *how* you're going to use the information, then there's no use in speculating about the "best" way. As you know more about what you're going to do with the data, you'll get clues on how best to structure it.

For example: If *all* your reports are keyed from the user ID, then a single flat table (or flat file) may be perfectly sufficient. If the questions are grouped into categories and you report based on categories, you'll want to find a way to separate the questions...such as a different table for each category. If you find that questions are continually being added to the system, you'll probably want to put the question definitions into a table, etc.

So think about the entirety of the problem, then figure out what scheme will help you make the simplest (to write and maintain) code. Give a slight nod to expected "expansion" by not making design decisions that make expected changes too difficult.