Modeling questionaire responses - database

Wondering what is the best way to model out a questionnaire in terms of saving the response. So I would assume the ideal way to save it would be a table like this:
ID_pk
response_id
question_id
value
So each entry would be an answer to a question. The question is when I search on this table the performance would be bad. I was wondering do I need to create another table on the side to help me with performance. Any ideas?
Thanks

The best approach depends on how flexible you need this to be. Will you have multiple choice questions? Numeric-only questinos used for calculaitons? True/False questions, etc.
The approach that worked for us to enable ultimate flexibility has this structure:
Table: Surveys
SurveyId PK
Surveyname
Table QuestionTypes
QuestionType PK
QuestionTypeText (ie "Multiple Choice", "True/False", etc.)
Table Questions
SurveyId FK
QuestionId PK
QuestionText
QuestionType
Table Answers (Contains answers ONLY for multiple choice questions)
Answerid PK
QuestionId FK
AnswerText
Table Results
ResultId PK
Surveyid FK
QuestionId FK
QuestionType (copied in from Question)
MultipleChoiceAnswerid (null unless it was a multiple choce question, FK to Answer otherwise)
BooleanResult (if QT = boolean, null otherwise)
NumericResult
FreeFormTextResult
and then a lot of programming logic to handle the display.
Actually, our real soultion goes a stp further and groups questions into QuestionGroups so that similar questions can be kept together, but this simplified version should give you some ideas. It's relatively complex, but I've seen professional survey software that's even more so, but follows a similar pattern. it's also worked out very well for us. We've been able to reuse it for several scenarios by creating a new SurveyType.

The idea is that anything that can be duplicated in a table should be pulled out to another table.
Question would be duplicated, so you'd need a questions table
Response could be duplicated, depends on if this would be multiple choice or fill in the blank, etc.
Value could be duplicated, but depends on the answer from Responses
So, I'd say to think about your questionnaire. Think about what would be saved multiple times in the db and then normalize from that.
Don't worry about performance - normalization will help more than it will hurt.

Related

How to model a 'history' table from a join table

I have a need to track some history for a table that contains ids from other tables:
I want to track the status of the company_device table such that I can make entries to know when the status of the relationship changed (when a device was assigned to a company, and when it was unassigned, etc). The company_device table would only contain current, existing relationships. So I'd like to do 'something' like this:
But this won't work, because it requires there to be a record in company_device for the FK to be satisfied in the company_device_history table. For example, if I
insert into company_device values (1,1);
insert into company_device_history values (1,1,'Assigned',now());
Then I can't ever remove the record from company_device because of the foreign key constraint. So I've currently settled on this:
so I'm not restricted by the foreign key.
My question is : is there a better way to model this? I could add the status and effective_date to the company_device table and query based on status or effective_date, but that doesn't seem to be a good solution to me. I'd like to know how others might approach this.
When looking exclusively at the problem (that is, when modeling the nature of the business problem at hand), the only thing you need is one single table COMPANY_DEVICE_ASSIGNMENT with four columns C_ID, D_ID, FROM and TO, telling you that "device D_ID was assigned to company C_ID from FROM to TO".
Systems do exist that allow you to work on this basis, however none of them speak SQL (an excellent book with an in-depth treatment of the subject matter of temporal data, I'd even call it the "canonical" work, is "Time and Relational Theory - Googling for it can't miss). If you do this in an SQL system, this "straightforward" approach is not going to get you very far. In that case, your practical options are limited by :
what temporal features are offered by the DBMS you want/can/must use
what features are supported by whatever modeling tool you want/can/must use to generate DDL.
As Neil's comment stated : the most recent version of the SQL standard had "temporal support" as its main novelty, and they are absolutely relevant to your problem, but the products actually offering these features are relatively few and far between.

Questionnaire to database design

I have read through a lot of the threads here and have found a good amount of useful input...but there are a couple of questions that remain unanswered.
I am storing questions & answers from a questionnaire in a database.
I have the tables:
Survey (surveyID)
Question (questionID, surveyID, questionType, Question)
Answer (answerID, userID, questionID, answer)
User (userID, username)
Question 1: multi-value questions...I would have a separate row for each value in the answer table....but have the same questionID and userID. But then how would you work the following:
-what are your coping strategies (multi-value)
-how frequently do you use each coping strategy?
i.e. a one-one relationship of coping strategy-frequency.
The solution above (i.e. one row per answer doesn't work because you need the relation between the specific coping strategy and the frequency).
A similar question is for the following:
have you been involved in conflicts over land-use rights?
with whom? (multi-value)
for what reasons?
(i.e. what were your reasons for conflict with the neighbours, what were your reasons for conflict with the authorities?) ...i.e. one to many on a multi-value attribute
Thank you in advance, I hope I have explained my query sufficiently well.
Becky

What is the best DB model for multiple answer questions

I need to store in a DB (MSSQL) multiple answer questions, and I am having trouble deciding what is the best way to do so. Should I store questions in one table, all answers in another and right answers in a 3rd table? Should they all be in the same table?
I would love to hear your ideas
thanks
Amit
Each concept, or entity, should be in its own table.
Questions in a Question table
Answers in an Answer Table with a QuestionID with a boolean field indicating its right or wrongness
(unless Answers can belong to more than one question?)
To me in your case best way is to hold question and answer in seperate tables. If your question has multiple answer and you maybe want to use one answer in a lot of question its the best way. You should also add table for which answer is good for specific question.
In this way you don't have data redundancy in database.
I agree with podiluska.
Each entity in a table.
If all or any of answer can be "typified" (i.e. not "free answer"), add a table for "typified answers" relating this one with table questions (to prevent someone to choose inapplicable "typified answers".
In table "user answers" relate it with table "questions" and if some record (or answer) contains a not "typified" you can mark it with a boolean column indicating "right" or "wrong".
I hope have helped you.

Complex Database Relations (Junction Tables)

My Question is about the idea of combining two junction tables into one, for similarly related tables. Please read to see what I mean. Also note that this is indeed a problem I am faced with and therefore relevant to this forum. It is just a topic of broad consequence for which I'm hoping to elicit a bit more participation from various professionals to get a better census of "best practice" if you will.
I have this rather challenging database design problem. I'm hoping this will be sort of a wiki that many people can contribute to and learn from. To make this easier, I've created a set of graphics, and will break the problem down into 1) Process, and 2) Structure.
Process Steps
A request (DocRequest) for documentation (Publication) is made.
A new publication is created IF said publication does not already exist.
A running log (StatusReport) is kept for progress on fulfilling the request.
Note: For any given Publication there may be many DocRequests and StatusReports (including updates)
Database Structure
Note: Both the DocRequest and StatusReport tables have numerous fields and supporting tables not shown in the attached graphics. Furthermore, a particular Publication is the master record to which all records in those tables belong.
--Current Implementation--
Note: The major flaw with this design is that whenever you create either a new DocRequest and StatusReport record, you have to also create a new record in the Publications table (which acts like a junction table), but this also creates a new Publication as a result. This is not the desired behavior.
--Typical Implementation-- (for this type of relationship)
Note: This is ok, and probably ideal, but handles updates to either the DocRequest and StatusReport tables, independently linking them to the Publication to which they belong.
--My Preferred Implementation-- (for this special case)
Note: The idea I had here, was simply to combine the dual junction tables into one. In this case the junction table would get a new record anytime either the DocRequest or StatusReport had a insert occur. I will likely handle this with a trigger.
Discussion
Now for the discussion. I would like to know from my fellow Database Developers if you think this is a bad idea, and what issues might arise from this. I think the net number of records should be identical as with the two separate junction tables, and in fact uses slightly less space by saving an extra ID column. :)
Let me know what you guys think. I would really like to get many people involved in this discussion. Cheers! :)
I think you're hurting yourself by thinking in terms of junction tables. Just think of tables.
Since StatusReport has to do with the status of the document request,
you need a table that relates those two somehow.
"StatusReport" is an awful name for a table that stores facts about the status of a document request.
"ID" is an awful name for any column in any table.
The id number of the publication seems to have more to do with the document request than with the status of the request. (You said, "A new publication is created IF said publication does not already exist." Frankly, that's skating pretty close to the edge of not making sense.) So the publication number almost certainly belongs in the DocRequest table.
Referring to the diagram of your preferred implementation, I'd drop the table TripleJunction, and replace StatusReport with this.
-- Predicate: Document request number (doc_request_id) has status (status)
-- as of date and time (status_as_of).
create table document_request_status (
doc_request_id integer not null references DocRequest (id),
status_as_of timestamp not null default current_timestamp,
status varchar(10) not null,
-- other columns go here
primary key (doc_request_id, status_as_of)
);

Save multiple questions in one row

I need to make a scheme for an database. My problem is, that I have multiple questions they belong to one exam. That means: One Exam has multiple Questions. I don't know how I can solve that. I have try to fix it with an table between "tabQuestions" and "tabTest" but I doesn't seems to be the correct approach.
I have the following tables:
tabTest: ID, Name, FK_Categorie, FK_Questions
tabQuestions: ID, Question, FK_Answer
tabAnswers: ID, Answer, FK_Solution
tabSolution: ID, Solution
Thank you very much for the help!
Luca
You don't need the FK_Question field in your tabTest. What you need is a FK_Test field in your tabQuestion table where you store the id of the test the question belongs to.
...if I understood you right...?
And if I understood you right, then you should use the same for the rest of the schema too. This means you need a reference in your solutions table where you store the answer the solution belongs to etc.
You need to create two tables for this. One for exam (test) and one for questions.
The table exam (test) should have:
test_id, test_name
The table question should have:
test_id (references test_id from test table),
question_id ,
question_text.
Now you can have a 1:n relationship where one test has many questions.
But do not, I repeat: do not, store multiple questions in one row. That violates every possible good database design. Your selects, updates and inserts will be near impossible to write.
This website seems to have very good pointers for you.

Resources