Im creating an optimized database for online exam module.
I have two choices:
Schema with which Im storing the question, options and answer in same row.
Table: questions
Col: q_id, question, opt1, opt2, opt3, opt4, opt5, ans
Schema with which Im having 3 different tabled for each operation.
Table: questions
Col: q_id, question
Table: options
Col: q_id, opt_id, option
Table answers
Col: q_id, ans
Schema 2 is more along the lines of what you should be aiming for.
There could be a 3rd option:
q_id | question | options | answer
where the option column is of type text and stores a serialized array or json.
For the 2 options you provided: the 2nd one world be the weapon of choice
I would use schema 2, as it allows you to add an arbitrary amount of answers.
You could however incorporate the answers table in the options table.
q_id | opt_id | option | correct
In this way you can also have multiple correct answers per question.
Schema 2 would be the better option if you want to stay flexible in your exam options.
However, if you are sure you can set a fixed amount of questions every time, you might want to consider putting table "questions" and "options" into one and just having the answers vary for each user.
If there is a fixed number of answers schema 1 would be better
but if the question may have any number of answers this would be better
question_id,question,answer_id_of_the_solution
answer_id,question_id,answer
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am creating a system where users (who are identified by a user id number) will be allowed to vote on posts (think Reddit, StackOverflow, etc).
Users can vote a post up or not vote at all on it.
The number of votes on a given post can easily be stored within the table containing the posts.
Keeping track of who has voted, however, is a different task entirely that I'm not sure how to approach.
I was thinking I could have a table that would have two columns: user id and post id.
When they vote on a post, I add their user id and post id to that table. If they unvote, I remove that entry from the table.
EG:
User ID | Post ID
1 | 3949
1 | 4093
2 | 3949
etc...
Is this a reasonable solution?
Yes this is reasonably simple and easy solution to the problem. You can do the same for your comments(if you like to). In your MAIN_POST table assign a post_id and use this same post_id in other tables (comments(post_id, user_id, post_comment, comment_time) and votes(post_id, user_id, vote_status(you can use 1 for vote up and 0 for vote down))). It will complicate your sql queries, to retrieve data, a little but you can do it. And on android side there are alot of tricks to handle and furnish this data in application and you can make this vote(like) and comments idea just like facebook (YOU for your comments and likes and NAMES for others).
I wouldn't remove rows from the table. I understand why you would want to do that, but why lose the information? Instead, keep a +1/-1 value for each entry and then sum up the values for a post:
select sum(vote)
from uservotes
where postid = 1234;
And, I agree with Rick that you should also include the creation date/time.
Using an 'in between' or 'joining' table is a perfectly acceptable solution in this case. If relevant you could even add a timestamp to the relation and show to the user when a user has upvoted something.
Also it is important to take care of proper Indexes and Keys to have your table structure also perform properly once the dataset grows.
I have a simple form that asks "how are you doing right now at this moment?" and they select #1-10 from a dropdown.
The challenge: the user will answer this question endlessly over time, and I'd like to, if possible, store their ongoing answers in 1 column of a record with their unique user_id. Since they can potentially have hundreds of submissions to the question, what would the best way to store and retrieve their stored answer? There will be an option for them to view their past 5, 10, or even 100 answers so they can see a pattern over time how they're doing. Their info would be displayed probably in a table going across the screen like:
Here's how you've been doing:
2 4 8 9 4 9 4 etc etc
Is there a way, and is it in this case recommended, to save all their submitted answers to the question in 1 single table row column? If so, can you give me an idea of the mysql code to save ... and code to retrieve it? I would create x # of columns to save each answer if there was a known total, but in this case, we don't know how many there will be.
I wasn't able to find a solution to online.
Yes , according to the Jeff, If I were you, I will create some table that we call it temporary_answer with the field,
user_id, question_id, answer_id, created_datetime
And you will able to fetch this temporary answer anytime, anywhere by filtering the user_id and created_datetime. I have done with this when I was developing e-learning sites. I hope this answer can help.
CMIIW.
I have a game. In the game, people make many choices out of 2 options.
The choice can be either right or wrong and I am storing the result of their run through the game (which can be a very large length) as a string with 1 for a right answer and 0 for wrong answers.
So for example, player 128937 will have stored in his run column the string 00010101010010001010111 as a varchar(5000).
Is there a better way I can store this information in MYSQL? (I am using PHP too if that can help)
I would create a new table (say it's called 'answers') with three columns:
question_id,user_id and answer (which will hold values of 0/1 )
every time the player answers a question you INSERT a new entry to this table.
This way it'll be easier to maintain the sum of right/wrong answers
Why not use a tinyint(1) for each option rather than using strings?
I would make multiple tables
choices
id
scenario (or other title)
options
id
choice_id
title (example: "go left" or "turn around and go home"
correct (0 or 1)
user_choices
user_id
option_id
choice_id (optional since choice_id is already in options table)
I have 3 database tables and I need to normalize them. The association between tables like this:
Tables:
1. question
2. answers
3. comments
(question can contain many answers and many comments)
(answers can contains many comments)
I know I could use questions and answers in one table and then I solve the problem, but I want to use it this way, so what's the best way to associate 'comments' with 'questions' and 'answers'?
I tried to put question id and answer id into the table of comments and use only one of them for each row, is this right? this way I can use them in php script but I don't know if there is another better way because that I asked.
Thank you.
I would set them up as follows:
Posts (both Questions and Answers would be types of "Posts"):
Post_ID
[Fields Common to Posts, e.g. "Post_Content", "Poster_ID", "Post_TimeStamp" etc.]
Questions:
Question_ID
Post_ID
[Question-specific fields, e.g. "Question_Title"]
Answers:
Answer_ID
Post_ID
[Answer-specific fields]
Comments:
Comment_ID
Post_ID
[Comment fields]
The main idea of having a seperate Posts table is to normalize your database, and allow for a logical structure for comments to point to both. Like APC commented, it also gives you a good setup for developing your site/database going into the future (when you might want other types of commentable "Posts."
While the enum method listed below would work, it's not good database design. In general, I would suggest only using ENUMs when you're representing a real world list of items.. not for organizing your database structure.
Use an extra type field in the comments table which holds "question" or "answer" for a polymorphic association. Queries then just include that field:
SELECT * FROM `comments` WHERE `type` = 'question' AND `foreign_key` = 42
I'm making an online quiz with php and mysql and need a bit of help deciding how to design the database for optimal insert of questions/answers and to select questions for the quiz. The table will hold 80 questions each with 4 possible options plus the correct answer.
When retrieving the questions and options from the database I will randomly select 25 questions and their options.
Is it better to make a single column for all questions, options, and correct answers? For example:
ID | Q | OPT1 | OPT2 | OPT3 | OPT4 | ANS
Or would it be better to make a column for each individual question, option, and correct answer? For example:
Q1 | Q1_OPT1 | Q1_OPT2 | Q1_OPT3 | Q1_OPT5 | Q1_ANS | Q2 | Q2_OPT1 | Q2_OPT2...
It'd be better to store the possible answers in a seperate table. This allows you to have any amount of answers per question instead of just 4. It also allows questions to have a different number of answers. If you have more than one quiz, you may also want a Quizes Table.
Quizes:
id
name
Questions:
id
quiz
prompt
Answers:
id
question
prompt
QuizResult (someone taking a quiz)
id
quiz
// other information about the quiz taker, possibly including the time
Now the correct answer thing gets a lot more tricky. I prefer the higher implementations here:
Each question has a value and each answer has value
A system I recently worked with you could assign a point value for each question and each answer. Incorrect answers often got 0, correct answers got the full amount. You could also have partially-correct answers using this method. This is the method I would go with.
You could go and say every question is worth 10 points or you could assign different weights to different questions:
Questions:
id
quiz
prompt
value (you can make this question worth more or less)
Answers:
question
prompt
value (you can make this answer worth more or less)
Store the correct answer in the Answers Table
A more simple (but less robust) solution is to simply say which answer is correct in the Answers table.
Answers:
question
prompt
is_correct
Store the correct answer in the Questions Table
I wouldn't recommend it. When you create a question, it won't have a correct answer until you insert one. This means at least 3 queries to correctly make a question. If you use foreign key dependencies, this will quickly get annoying.
Go with option 1 where you are having one row for each question/options/answer.
Option 2 does not make any sense. Every time you want to add/delete a question you'll be modifying the database schema!! And you'll have just one row always !!
Go for your first option. It is the most normalised option, but that isn't necessarily a clinching argument. But the virtues of the normalised design are manifold:
it is a piece of cake to include new questions into your quiz portfolio. (The other option requires adding new columns to the table).
it is simple to write the select statement which returns the result set. (the alternative option requires a dynamic SQL)
it is easy to write a GUI which displays the questions and answers, because each displayed set of text maps to the same coilumn_names.