I am trying to build a table for Multiple Choice Question system where each question has unbounded number of choices to select from(Not a fixed number of choices). These number of choices vary from question to question.I am trying to build a database which stores the question as well as the choices.
Table Question
{ // Though just two fields are shown, there are many fields in the table actually
questionId;
question;
}
Table Choices{
choiceId;
questionId;
choice;
}
One can argue that we can dynamically enter the choice directly into Question Table by having a field but this duplicates the other field data. Like if we have 10 choices for a single Question,then we would have 10 rows in Question table with a lot of duplication. So I have separated the Tables as Question and Choice.
The main problem here. We do not know what the question Id is till the question is actually created. We cannot use the Question Id from the Questions table during entering data into the Choices Table. Any suggestion on how to do this?
Your structure would be able to handle the requirement you are looking for. In the table Choices you can use a primary key combining questionID and choiceID so that you can use choideIDs starting from 1 for each of the questions rather than trying to find out which ID the choices start for each question.
As for your problem on not knowing what questionID is generated, assuming your questionID is an auto_increment column, you can use your last_insert_id function in whatever programming language you are using to find out what questionID was generated by the last insert. As you will be having multiple entries for the choices, it would be hard for you to do this in a single SQL insert command.
If you are using Entity Framework...
You should save Question (Even field "question" is empty) and get ID...
If User Cancels everything just remove that question by ID...
Related
I am currently in the process of creating my tables for a survey/questionnaire system. As I got to creating the questions table, I think I came across a slight issue that could impact the whole application if I continue. Within my questions table, I have a column called "subBelongsToQuestion", which is an integer value for identifying which sub-questions belong to which parent questions (if any). Then in my answers table, I have a column called "responseRevealSubQuestion", which is an integer value for identifying which sub-questions to reveal if the trigger answer within the "responseRevealSubQuestion" column value matches with the "response" column value.
So for example, if a user answered yes to a question such as "Do you like cheese?", then a sub-question would appear saying "What do you like about cheese?".
I am wanting to convert this vision into a database format and I wasn't sure if I should continue with the approach I am using, or to change? It is so that if say a user deletes a question that contains sub-questions, then the application can run the required code to also delete the sub-questions and trigger answers as well.
Usually for survey apps you dont use SubQuestions, you define flow conditions
Imagine you have this questions on your db
Q_ID Question
1 Do you like cheese?
2 What do you like about cheese?
3 Do you like meat?"
4 What do you like about meat?
5 ...
Then you have a flow table to validate after one answer.
Q_FROM Q_VALUE Q_TO
1 NO 3
3 NO 5
In this case you only take detour for NO answer. otherwise you continue with the next question.
After your end each question you do
SELECT Q_to
FROM FlowTable
WHERE Q_from = #CurrentQuestion
AND Q_value = #CurrentAnswer
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I would like to know if it is possible to have the following database behaviour:
Create a USER table, with primary key USER_ID
Data comes in from external source: e.g. "USER_ID, TIMESTAMP, DATA"
For each user in the USER table, create a table to store only data entries pertinent to USER_ID, and store all incoming Data with the correct USER_ID into that table
When querying all the data entries for a specific USER_ID, just return all rows from that table.
I could of course do this all in one table "ALLDATALOG" and then search for all entries in ALLDATALOG that contain USER_ID, but my concern is that as the ALLDATALOG table grows, searches will take too long.
You should not split your tables like that. You will want an index on the USER_ID column in your data log table. Searches do become slower as data size increases, but your strategy will not necessarily mitigate that. It will however make your application more complex to write, harder to debug, and quite likely actually slow it down.
You should also consider unpacking that data blob into additional columns and tables as appropriate in order to take advantage of the relational nature of the database.
How many rows do you expect the table to hold over time? Thousands? Millions? Billions? At what rate do you expect rows to be added?
Suggestion 1: As answered by Jonathan, do not split the tables. It won't help you increase the speed.
Suggestion 2: If you still want to split the tables. Use the logic in your PHP code. Check if the table for a particular use already exists or not. If it does, insert values in it and if it doesn't create a new one. Should be quite straight forward. If you want me to share code for this, let me know.
Im designing a poll application, where the user creates one or several polls whith questions and predefined answers for each question, so far no problem, im thinking the easiest way to do this is with 3 tables:
Polls Table:
id title description
Questions table:
id poll_id question
Answers table:
id question_id answer
The problem is, the user may select a different behavior on the questioning flow of the poll, for example a normal poll will go from question 1 to question N (being N the final question), but in my case the user may want if the user choose answer 2 of question 4 to jump to question 7 and ignore the rest between them.
Im a bit confuse about how to store in database this behavior, any suggestions?
Looks like you need something similar to this:
Look at the construction of keys here:
The QUESTION is in identifying relationship with POLL and the resulting natural key provides not just uniqueness but ordering as well: QUESTION_NO can monotonically increase while keeping the same POLL_ID.
The equivalent effect is accomplished by ANSWER_NO in POSSIBLE_ANSWER.
The user can pick at most one answer for any given question. That's why ANSWER_NO is outside of the ACTUAL_ANSWER primary key.
On the other hand, USER_ID is kept inside the ACTUAL_ANSWER PK, to allow the same answer to be picked by more than one user.
Theoretically, there should be a key in QUESTION_TABLE on {POLL_ID, QUESTION_TEXT}, to prevent two different questions having the same text in the same poll. However, QUESTION_TEXT might be long and is potentially implemented as BLOB, which most DBMSes can't index or constrain by a key. The similar dilemma exists for POSSIBLE_ANSWER.ANSWER_TEXT.
If user skips a question, just omit the corresponding ACTUAL_ANSWER.
Answer > NextQuestion table
AnswerID NextQuestionID
Based on your answer, the next question is defined in here
This question is related to this post:
SQL design for survey with answers of different data types
I have a survey app where most questions have a set of answers that are 1-5. Now we have to do questions that could have a variety of different answer types -- numeric, date, string, etc. Thanks to suggestions from stack, I went with a string column to store answers. Some questions are multiple choice, so along with the table 'questions', I have a table 'answers' which has the set of possible answers for a question.
Now: how should I store answers for a question that is "pick all that apply"? Should I make a child table that is "chosen_answers" or something like that? Or should the answers table have a 'chosen' column that indicates that a respondent chose that answer?
a possible solution is a UsersAnswers table with 4 columns: primary key, user's id, question's id, and answer's id
with multiple entries for any questions where more than one answer can be selected
I have two suggestions.
Normalize your database, and create a table called question_answer, or something that fits more in line with the nomenclature of your schema. This is how I would lay it out.
CREATE TABLE question_answer (
id INT NOT NULL AUTO INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
question_id INT NOT NULL,
answer_id INT NOT NULL
);
Create five columns in your answers table, each of which refers to a specific answer. In MySQL I would use set these columns up as bit(1) values.
IMHO, unless you see the number of choices changing, I would stick with option 2. It's a faster option and will most likely also save you space.
As you're not going to have many options selected I'd be tempted to store the answers as a comma-separated list of values in your string answer column.
If the user is selecting their answers from a group of checkboxes on the web page with the question (assuming it is a web app) then you'll get back a comma-separated list from there too. (Although you won't just be able to compare the lists as strings since the answer "red,blue" is the same as "blue,red".)
Another option, (And I've seen cases where this was how questions like this were scored as well), is to treat each possible answer as a separate Yes/No question, and record the testee's response (Chose it, or didn't) as a boolean...
these survey questions always have one, universal answer: it depends on what you want to do with the answers when you're done.
for example, if all you want to to is keep a record of each individual answer (and never do any totaling or find all users that answered question x with answer y), then the simplest design is to denormalize the answers in to a serialized field.
if you need totals, you can probably also get away with denormalized answers in to a serialized table if you calculate the totals in a summary table and update the values when a quiz is submitted.
so for your specific question, you need to decide if it's more useful to your final product to store 5 when you mean "all of the above" or if it's more useful to have each of the four options individually selected.
this is a follow-up question on my previous one.We junior year students are doing website development for the univeristy as volunteering work.We are using PHP+MySQL technique.
Now I am mainly responsible for the database development using MySQL,but I am a MySQL designer.I am now asking for some hints on writing my first table,to get my hands on it,then I could work well with other tables.
The quesiton is like this,the first thing our website is going to do is to present a Survey to the user to collect their preference on when they want to use the bus service.
and this is where I am going to start my database development.
The User Requirement Document specifies that for the survey,there should be
Customer side:
Survery will be available to customers,with a set of predefined questions and answers and should be easy to fill out
Business side:
Survery info. will be stored,outputed and displayable for analysis.
It doesnt sound too much work,and I dont need to care about any PHP thing,but I am just confused on :should I just creat a single table called " Survery",or two tables "Survey_business" and "Survey_Customer",and how can the database store the info.?
I would be grateful if you guys could give me some help so I can work along,because the first step is always the hardest and most important.
Thanks.
I would use multiple tables. One for the surveys themselves, and another for the questions. Maybe one more for the answer options, if you want to go with multiple-choice questions. Another table for the answers with a record per question per answerer. The complexity escalates as you consider multiple types of answers (choice, fill-in-the-blank single-line, free-form multiline, etc.) and display options (radio button, dropdown list, textbox, yada yada), but for a simple multiple-choice example with a single rendering type, this would work, I think.
Something like:
-- Survey info such as title, publish dates, etc.
create table Surveys
(
survey_id number,
survey_title varchar2(200)
)
-- one record per question, associated with the parent survey
create table Questions
(
question_id number,
survey_id number,
question varchar2(200)
)
-- one record per multiple-choice option in a question
create table Choices
(
choice_id number,
question_id number,
choice varchar2(200)
)
-- one record per question per answerer to keep track of who
-- answered each question
create table Answers
(
answer_id number,
answerer_id number,
choice_id number
)
Then use application code to:
Insert new surveys and questions.
Populate answers as people take the surveys.
Report on the results after the survey is in progress.
You, as the database developer, could work with the web app developer to design the queries that would both populate and retrieve the appropriate data for each task.
only 1 table, you'll change only the way you use the table for each ocasion
customers side insert data into the table
business side read the data and results from the same table
Survey.Customer sounds like a storage function, while Survey.Business sounds like a retrieval function.
The only tables you need are for storage. The retrieval operations will take place using queries and reports of the existing storage tables, so you don't need additional tables for those.
Use a single table only. If you were to use two tables, then anytime you make a change you would in effect have to do everything twice. That's a big pain for maintenance for you and anyone else who comes in to do it in the future.
most of the advice/answers so far are applicable but make certain (unstated!) assumptions about your domain
try to make a logical model of the entities and attributes that are required to capture the requirements, examine the relationships, consider how the data will be used on both sides of the process, and then design the tables. Talk to the users, talk to the people that will be running the reports, talk to whoever is designing the user interface (screens and reports) to get the complete picture.
pay close attention the the reporting requirements, as they often imply additional attributes and entities not extant in the data-entry schema
i think 2 tables needed:
a survey table for storing questions and choices for answer. each survey will be stored in one row with a unique survey id
other table is for storing answers. i think its better to store each customers answer in one row with a survey id and a customer id if necessary.
then you can compute results and store them in a surveyResults view.
Is the data you're presenting as the questions and answers going to be dynamic? Is this a long-term project that's going to have questions swapped in and out? If so, you'll probably want to have the questions and answers in your database as well.
The way I'd do it would be to define your entities and figure out how to design your tables so relationships are straightforward. Sounds to me like you have three entities:
Question
Answer
Completed Survey
Just a sample elaboration of what Steven and Chris has mentioned above.
There are gonna be multiple tables, if there are gonna be multiple surveys, and each survey has a different set of questions, and if same user can take multiple surveys.
Customer Table with CustID as the primary key
Questions Table with a Question ID as the primary key. If a question cannot belong to more than one survey (a N:1 relationship), then can also have Survey ID (of table Survey table mentioned in point 3) as one of the values in the table.
But if a Survey to Question relationship is N:M, then
(SurveryID, QuestionID) would become a composite key for the SurveyTable, else it would just have the SurveyID with the high level details of the survey like description.
UserSurvey table which would contain (USerID, SurveryID, QuestionID, AnswerGiven)
[Note: if same user can take the same survey again and again, either the old survey has to be updated or the repeat attempts have to stored as another rows with some serial number)