Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / General DB Topics / General DB Topics / June 2003

Tip: Looking for answers? Try searching our database.

Database structure for question/answer data storage

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
dansan - 26 Jun 2003 21:04 GMT
Hello all!

I have found myself in a quandry.  While building our database, we
have discovered that our employees have to fill out a questionaire.
The previous db used had every question in the questionaire stored in
the same employee table.  Every question was therefore a new column in
that table.  This is, IMHO BAD stuff.  Some of the questions have
'sub-questions' that only need to be answerd if the 'parent' question
is answers in a specific way (such as YES).

The deal is that if I decide to split this up, so that I have:
* A questionaire table with columns: (questionaireID, questName)
* A quesitions table with columns: (questionID, questinaireID,
question, answerType)
* An asnwers table with columns: (answerID, questionID, answer)

This would force me to store all of my answers in 1 datatype.  All of
my answers would probably have to be some type of varchar(80) or
something like that.

Is there any other structure that you have used for this type of
problem?  How well did it scale?  Would it be possible to change
questions with your idea?

Thanks for your thoughts.

Dansan.
programmer - 30 Jun 2003 11:00 GMT
> I have found myself in a quandry.  While building our database, we
> have discovered that our employees have to fill out a questionaire.
[quoted text clipped - 17 lines]
> problem?  How well did it scale?  Would it be possible to change
> questions with your idea?

I'd probably go for something like this:

(QuestionaireVersion, QuestionNumber, QuestionText, PreRequisiteQuestionNo,
PreRequisiteAnswer)
Primary Key(QuestionaireVersion, QuestionNumber)

(QuestionaireVersion, EmployeeId, QuestionNumber, Answer)
Primary Key(QuestionaireVersion, EmployeeId, QuestionNumber)

The PreRequisiteQuestionNo and PreRequisiteAnswer fields would be for the
questions which are dependent on the answer to previous questions.
dansan - 30 Jun 2003 15:34 GMT
There would be no way of determining the type of the answer :(  It
would be nice to be able to have different 'types' in there, but I
haven't come up with an idea I like.  I like the table set up that you
have suggested.  Maybe in the 'questions' table, there can be an extra
field 'answerType', which would allow for metadata type information
about the answer.  Does that sound silly?  Is there any major
draw-back to that?

Thanks for your ideas.

Daniel.
programmer - 30 Jun 2003 16:25 GMT
> There would be no way of determining the type of the answer :(  It
> would be nice to be able to have different 'types' in there, but I
[quoted text clipped - 7 lines]
>
> Daniel.

You could put a field for matedata in there easily enough, but then the
application would have to enforce the type. This would be possible (with
some DBMSs) using triggers and stored procedures.
Bob Badour - 30 Jun 2003 16:35 GMT
> There would be no way of determining the type of the answer :(  It
> would be nice to be able to have different 'types' in there, but I
[quoted text clipped - 3 lines]
> about the answer.  Does that sound silly?  Is there any major
> draw-back to that?

It's not silly. It's actually quite common when creating a design to
describe mutually exclusive subtypes. Fabian Pascal's _Practical Issues in
Database Management_ (http://www.pgro.uk7.net/books.htm) has an excellent
chapter on this topic and chapters on many other interesting topics.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.