I'm currently working on a project, the admin of the application must be able to add/edit these information.
Class(className)
Teacher(teacherName,teacherInfo,teacherPicture,teacherEmail)
Practice(practiceName,practiceDate,practiceDescription,practiceDocs)
I tried making 3 tables of which the class would be the relational table containing the keys of teacher and practice, but that way I can't add only the subject without teachers and practices or add a Teacher and then afterwards assign him a class, or remove him from a class. So my question is how would I go about doing this or if you could point me to some good read for this problem.
If I understood it right, you have a practices table, a teachers table and a classes table, with relation fields put directly on those tables.
For you to be able to create teachers, classes and practices individually, you must take that relationship fields out and put the relations into separate tables.
So, instead of having, for example, a classes table with a teacher field, have a classes table without any field related to the teacher and another separate table classes_teachers where you'd have a unique identifier for the association, the id of the teacher and the id of the class.
The type of relationship your current schema provides is called a 1 by n relationship.
The kind of relationship you need is a n by n relationship.
Related
This question already has answers here:
Should junction tables have more than one primary keys from another identifying table?
(4 answers)
Closed 7 years ago.
I have two tables that I need to connect: discipline and class.
It will be a N:N relation, so I'll create a new table class_discipline.
Does my pivot table class_discipline may have more fields than just the Ids of the two tables ? Is it a good practice ?
If yes, is there some kind of rule that I should follow to do such a thing ?
Let me explain the situation: I'll import some data from an excel file, I can't change the data of this file (My university provides it).
And this file have some data that does not fit neither on discipline or class tables. So I guess I should insert this "extra data" into the pivot table.
Your table class_discipline can have as many columns as you want.
Generally any column in that junction table represents an attribute of the relationship. In this case if a relationship between class ad discipline needs any specification then yes, use more columns.
Example:
Assume you have tables students and courses. And to define who is enrolled in which course, you will create student_course table containing only student_id and course_id. But if you want to know when a student enrolled, you need to save this information somewhere (it's not an attribute of a student nor course). That's the time for adding new column into student_course table.
Good or bad practice?
Using additional columns in a junction table for attributes of the relationship is a good practice normally. However you need to keep in mind that you lose the column values if the relationship is removed.
Additional comments:
If you are using such structure in an application or via ORM, note that plain N:N relationship is a field of a class. Once you need more attributes of the relationship you need to have a separate class.
I have two type of user in my master table Doctor and Hospital both user has common fields like Name,Address,Contacts etc.
But there are some different fields which is connected by foreign key to this table
Like for Doctor it has
one to one relation with specialization and department table
and for Hospital
has one to one with service and one to many with facilities table
Now my question is What should be the database schema for this type of relation, At present I made separate table for both Doctor and Hospital but the fields like Name,Contact and Adreess repeating in both table.
It sounds like Doctor and Hospital are both subclasses of some superclass, and the fields that repeat in both of them are attributes of that superclass. Do some google searches with either of these two search terms: "Generalization/Specialization" or "Class Table Inheritance". That second term will show you some specific designs for implementing subtypes or subclasses in relational tables.
You might want to ask the question of in the Database Administrators area. There is a tag called "subtypes" over there with one question in it. It's asking the same thing you are, in a different case.
I am creating a DB for my project and I am facing a doubt regarding best practice.
My concrete case is:
I have a table that stores the floors of a building called "floor"
I have a second table that stores the buildings called "building"
I have a third table that stores the relationship between them, called building_x_floor
The problem is this 3rd table.
What should I do?
Have only two columns, one holding a FK to the PK of building and another holding an FK to the PK of floor;
Have the two columns above and a third column with a PK and control consistency with trigger, forbidding to insert a replicated touple of (idbuilding, idfloor)?
My first thought was to use the first option, but I googling around and talking I heard that it is not always the best option.
So I am asking for guidance.
I am Using MySQL 5.6.17
You don't need third table. Because there is one-to-many relationship between building and floor.
So one building has many floors and a floor belongs to one building. Don't get things complicated. Even though you need a table with composite keys, you should be careful. You need to override equals and hashCode methods.
I am still not confortable with that approach. I am not saying it is wrong or innapropriate, very far from that. I am trying to understand how the informations would be organized and how performatic it would be.
If I have a 1:* relationship, like a student may be attending to more than one subject along its university course within a semester I would Have the 3rd table with (semester, idstudent, iddiscipline).
If I try to get rid of the join table my relationship would be made with a FK inside student table or inside subject table. And it does not make sense to do that because student table is a table for a set of information related with registering the info of a person while the discipline table holds the data of a discipline, like content, hours...it is more a parametric table.
So I would need a table for the join.
I have three tables: Resumes, Orgs, and Resume2Org. Basically, Resume2Org is my many-to-many relationship table linking Resumes.resume_id to Orgs.org_id (so it only has those two keys in that table).
My question is, is it okay to use that many-to-many relationship table to store other data? My use case: the database is part of a system to sift through incoming resumes. But I've been asked to implement a "marked as read" feature so we can easily get the list of resumes we haven't looked at yet. But since a resume can belong to many different orgs, we only want to mark a resume as read for the org the user/viewer belongs to. I thought, hey, having that flag in Resume2Org would be perfect. Is this a smart approach, or should I create a new table specifically for "marked as read"? All the examples I've seen about many-to-many relationship tables is that those tables are used just for that... linking two tables.
Yes it is okey to have additional fields in a many-to-many table. I think it is the right way to do in your case as you don't need to join additional tables and you save spaces.
I was in a very similar situation last week and I added additional field for that.
im new to mysql, and my first project would be to create a database of students-classes scenario.
i have decided to make a table "students" then thought each student could possibly be a member of one or more classes, so in my mind there would be a column in the students table that says "classes" now what data type would be appropriate for that? a class would consist of a string for name, then schedule (MTh, 10:30-11:30). Or should i instead just make a "classes" table then one of the columns would contain all the names of the students that belong to that class, then what data type should be used for a long "list"-like strings?
Each class can have many students, and each student can have many classes. Therefore your dilemma is whether to record the students in the classes table, or the classes in the students table.
In a relational database, you should have three tables:
one table for students;
one table for classes;
one table that has the pairings: one row each for one student being a member of one class.
It's far more flexible and general-purpose to do it this way.
See also my answer to Is storing a delimited list in a database column really that bad?