So I want to design a database schema for MCQ website in which I have several sections ,Lets say 3. and these section will have many sub-sections each.
I want to store the questions, choices and correct ans in such a way that every questions of sub-topics get stored in same table but questions of different section`s sub-section get stored in different one.
but,I don't know how to design a database schema like this. or what else could be better Approach ?
Possibly something like above? You have a section that can have as many questions associated as you want. Then a question that can associate with as many answers as you want. But the FK "answer_ID" under "Question" is a single "answer_ID" from the "Answers" table which tells you what the correct answer is. May not be the best but at least it would be a start. EDIT: the lines on the chart are wrong, sorry.
Related
I want to make a demo application that is able to ask a user if he/she has followed the correct methods to build an item.
I have created a 'checklist' for the user to fill in as he/she builds the item. For example some of the questions could be:
Have you received the correct parts?
Are the parts in good condition?
Are you building a chair?
Do you have the correct specifications for the chair?
...
...
...
And so on...
So these questions have yes/no answers only. My plan was to create a table and call each column by the questions' number. So column 1 will be called '1' and it's the first question. Column 2 will be called '2' and it's the second question and so on.
So this table will be called Chair inspection. I then have another table called Table inspection with its own set of checklist questions.
This data is captured using an android application. The development of the application is done. Just need advice on the database part.
Is this the correct approach to storing the user's inputs?
I advice you have three tables, one for the questions, the other for the users who will be answering those questions and the last one is for the answers, then you establish the relationship between those three tables. That means Many users can answer many questions. Therefore there will be many to many relationship between users and questions. Then there will be relationship between questions and answers and answer with the users who responded to the questions.
I think that way you will be able to avoid redundancy and simplify the process of updating, and retrieving you data.
A normalised schema might be as follows (incomplete, and ignoring 'tables' for the time being) :
inspection
inspection_id* item inspected_by date
inspection_detail
inspection_id* checklist_id* status
* = (component of) PRIMARY KEY
I am trying to learn ORM and better structuring a database. I am working on a simply quiz web app to try to learn the relationships between tables. Am I on the right track here?
Down below are my tables. And I was thinking like this:
Question has one answer.
Answer belongs to many questions.
Question has many alternatives.
Alternatives belongs to many
questions.
The tables
Question
ID
Question
Answer
ID
Answer
Alternatives
ID
Alternative
QuestionAlternative
QuestionID
AlternativeID
Consider a data model something like this:
You have a list of questions, each of which has zero, one or more offered options (possible answers). For each question, a user enters an answer. This answer may refer to a specific OPTION if applicable, or it could contain some kind of free-form information in the ANSWER table itself.
I'm currently working on a app that has a lot of different Model which are "likeable". This means each of them can be liked/disliked.
Is it better to create an unique table "likes", and referencing in each row the table reference + the table reference id, or to create an unique "likes" associated table for each likeable Model ?
It depends. It depends on many things. What you've described is only a small portion of the problem space I'm assuming. There are important questions to be asked here, like, "Do you need to keep track of what user 'liked' what model?" Answers to questions like that will heavily influence the design of this database.
Having a separate 'like' table hanging off of each model table is what we call de-normalized. It's not necessarily a bad thing, it just depends on what your plan is for this data store. The normalized approach would be to have a single 'like' table that all the model tables relate to.
For this, you really need more information. Once you have ALL of the requirements in place, it should become a lot more clear TO YOU, what the best approach is.
I'm writing an application to allow users to create a Poll. They ask a question and set n number of predefined answers to the question. Other users can vote on the answers provided for that question.
Current structure
I have designed the database like this:
Storing the vote count
Current thinking is, I create a new column called vote_count on the link table and every time that answer gets voted, it updates the record.
This works. But is it right? I'm new to database systems, so I can't imagine I'm doing much right. What are some more efficient ways to achieve this?
As far as it goes yes that's OK. However these tables will be incomplete. When your second quiz is created, you'll have to extend the QUESTIONS table. If this second quiz's Q1 also has a yes/no answer, you're going to have to extend the LINK/VOTES table.
You also have to think about how it's going to be queried and design indexes to support those queries.
Cheers -
I'm creating a small questionnaire, with below database design; following the schema from this thread made by Michael Durrant, with slight modification.
Now, for some questions, I must provide cities as options of answers; which already there in master_cities table.
Eg: Which city do you reside now?
Answer will be in dropdown format which derived from a master_city table.
I shouldn't copy the whole content of master_cities_table into option_choices table, should I???
Any ideas are greatly appreciated.
Edit: I'd like to clarify the question.
This question is totally unrelated with UI/UX, pure db design.
The goal I'm trying to achieve is to avoid data redundancies such as copying master table records into options_choices.
Since it's a survey system, all the choices of answers must be
database-driven, like A. Strongly agree, B. Neutral, C. Totally
disagree. Which could be reused to answer other questions, like
"Where were you born?" or "Which cities have you lived before?"
Master_cities table here is only one of the master tables (and the
biggest) that I need to refer to provide choices of answers.
Hope that clears the confusion.
Current approach:
I removed the referral_table field in options_choices table and put it
inside the options_group table instead,
set option_choice_id in answers table as NULL-able,
and save the master_cities primary key as text in answers_text field.
That seems to work.
But, there maybe a better approach out there, so you're welcome to share your insights, oh db experts!
Don't know. Usability would suggest that too long a drop down list won't be a good user experience.
Another approach would be to try type ahead, similar to what Google does when you start typing terms in the search text box, to look up city names. Once the user types a letter into the text box, you can narrow the query down and only present city names that match.