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.
Related
Might be a silly question to ask but what data type should I setup a column so I can enter multiple values?
Example: I have two tables, one called Application_users and the other Products.
Application_Users has an id column.
What I want is to have a column in Products which is called Application_Users_id and I enter 1,2,3,4
The idea is if an Application_User_id is say 3, they would only see products were the Products.Application_Users_ID contains a 3.
So what data type do I use so I can enter values such as 1,2,3,4 in a column?
I have tried NVARCHAR and INTEGER but neither work (NVARCHAR works but won't let me amend it e.g. add numbers).
Let me know what everyone thinks is the best approach here please.
Thanks
John
It might be a silly question but you would be surprised how many developers makes the very same mistake. It's so often that I have a ready-to-paste comment to address it:
Read Is storing a delimited list in a database column really that bad?, where you will see a lot of reasons why the answer to this question is Absolutely yes!
And if you actually go and read this link, you'll see that it's so wrong and so frequently used that Bill Karwin addressed it in the first chapter of his book - SQL Antipatterns: Avoiding the Pitfalls of Database Programming.
Having said that, SQL Server Does support XML columns, in which you can store multiple values, but that is not the case when you want to use them. XML columns are good for storing stuff like property bags, where you can't tell in advance the data types you'll have to deal with, for example.
tl;dr; - So what should you do?
What you want to do is probably a many to many relationship between Application_users and Products.
The way to create a many to many relationship is to add another table that will be the "bridge" between the two tables - let's call it Application_users_to_products.
This table will have only two columns - application_user_id and product_id, each of them is a foreign key to the respective table, and the combination of both columns is the primary key of the bridge table.
Database Design
Is this a bad design for a relational database. I don't see anyone doing examples that look like this.
But considering that an interview is comprised of all the different tables I have linked to the interview table it seems valid.
Except of OH Number (Oral History Number.) An oral history from one narrator may be comprised of different interviews conducted at different dates. Each individual interview is assigned a unique ID that make op a series that is assigned 1 OH Number.
I'm also thinking of putting "Interviewer, Indexer, and Transcriptionist in the same table.
I created the following mock-up for you given the details you have provided. I believe this will be a good starting place. You have an interview object and a person object. You have a joining table of InterviewPerson. This allows you to have one to many person objects per interview.
I want the database to be robust enough that if a researcher called in
and wanted all the interviews conducted by John Doe, on Race
Relations, I could pull a query for it.
To do the aforementioned as you have stated, you would join both the Interview table and the Person table on the InterviewPerson table, and then you would limit your query of that joining based on the Person.firstName, Person.lastName, Interview.topic (or title).
Please note, this is a rough draft but should be a good general idea and start.
Database Design Redux
This is what I came up with based on your suggestions.
I am new speaking about modelling databases. But I give my best to learn as much as possible by my own. Therefore I want to ask you, whether my first attemp make sense for the following example:
So I modeled the database as followed:
The databse is about medicine. There are several medicine items which should be dosed depending on the age of the patient. Every medicine item can belong to one ore more groups (or none).
This is just a test case to show what I learned so far. So every tip to improve my skills is welcome!
Thanks a lot!
The relationtable table name is just a placeholder, right? It should be more descriptive, maybe dosage?
Something tells me that age ranges will greatly vary. Some medicines have different rules for children under 3 years, other under 5, 10, and so on. Instead of creating a separate table, just include two extra columns (start and end) in relationtable. It will be much easier to query and I won't consider this a denormalization.
Talking about age and dose tables - get rid of unit column and use normalized, fixed unit. Years for age and mg for doses. This will make querying much simpler. Don't be afraid to use floating numbers, e.g. 0.5 to represent six months.
I agree with what Tomasz write and would like to add:
If the relationtable is the correct way to go depends on some knowledge not contained in the table. It sounds strange that one medicine can be part of different groups and that the dosage depends on that relation. I would expect that a medicine can belong to different groups (resulting in a medicine2group mapping table) and that their exist different dosages depending on the age for a medicine (so you get dosage4age table, combining the existing age and dose tables. That new table would directly reference the medicine)
Which version is correct can not be told from the table alone.
As a rule of thumb: I get skeptical when a table without a proper name and concept links more then two other table. It is possible but often hints at concept hiding somewhere.
In order to check if the proposed model is correct, ask the business experts if the table is still correct if you replace Antibiotika with Superantibiotika in one of the first three rows. If it is, this means that the dosage does not depend on the group and should not be linked to it, so the model proposed by me would be more correct.
If the altered table is not correct, your model might be the better one, but I would listen carefully about the explanation why it isn't correct.
I want to design a database to store crossword puzzles,
mainly I have 2 tables:
Questions Table, Grid Table,
Questions Table(q_id, question , answer...)
Grids Table (g_id, name, ....)
when I come to relate Questions Table with Grids Table, I am thinking of a good way,
Questions_Grid(q_id, g_id), the pair would be a primary key,
another solution that my boss suggested : Grids Table ( g_id, q_ids, ....)
q_ids store all the ids of the question used in this grid
which one is better? and if you have better options ?
It looks like your boss's suggestion is to store a list of question ids as a text column in the grid table. If I understand what you're asking and that's really it, the first one is much better, of course, because it's normalized. In your scheme, you can make many useful queries that would be messy or impossible (and slow, if possible) in your boss's scheme.
The first option is better, in that way the schema of your database does not restrict the number of questions per grid. A rule of thumb is that when you have to change the schema to make the application scale you haven't got an optimal schema.
a link table with one tuple pair is more normalized.
Question_grid
-------------
q_id
g_id
this will allow you to have as many questions as necessary for the grid, and no more.
if you try to hardcode the list, then each grid will need the same number of questions, or will have blanks or something.. no good.
Well the rule is to make a linking table when you have a "one"(grid) on "many"(questions) relationship. So your option would be the best answer, its normalized!
My application should contain list of questions + user answers. How should I organize the database:
question1 question2 question2 ... questionN
user_id_1 yes no yes ... yes
user_id_2 no no yes ... no
...
user_id_N yes yes yes ... yes
Looks like I need to create separate table with questions and assign id to each question. How another table should look like (since number of columns is not fixed)? Or, should I have 2 more tables?
Later on I will also need to:
calculate how many users answered 'yes' on questionN;
how many friends (another table or json data) of *user_id_N* answered 'yes' on questionN.
Should I query database each for getting these numbers, or should I have separate database and keep counters there each time user answer (looks possible for item 1 only since friends list can be changed anytime).
A standard way to do this is to store each answer as a separate entity - conceptually the same as you depict, but without the requirement to modify your structure as you add new questions. Here's an example set of model definitions that achieves this:
class UserInfo(db.Model):
# Anything you want to store about the user
class Question(db.Model):
text = db.TextProperty(required=True)
# Anything else you want to store about the question
class Answer(db.Model):
user = db.ReferenceProperty(UserInfo, required=True)
question = db.ReferenceProperty(Question, required=True)
answer_text = db.TextProperty(required=True)
If you are only storing whatever what answered, you should be able to do that with 3 tables. One for your questions with a one to many to a table with the answers and then another table for the users with a one to many to the answer they provided.
Using a separate table to keep track of the questions themselves might be a good idea. By the way, if you weren't simply leaving out a header for it, your list of user IDs should itself be a specific column in the answer table. It would probably be a good idea to use a separate table to keep track of who is friends with who, though.
Also, while I'm not experienced with accessing a GAE datastore, it's fairly simple to take a count of specific answers in a single column using SQL, at least. SELECT COUNT(questionN) FROM AnswerTable WHERE questionN='yes' would be what you'd use as an SQL query.
Note that if you went with Limey's suggestion for the design, the equivalent SQL query would be more like SELECT COUNT(answer) FROM AnswerTable WHERE questionID='questionN' AND answer='yes'.