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.
Related
This question already has answers here:
Foreign Key to multiple tables
(8 answers)
Closed 2 years ago.
So I have two tables -- Student table and Staff table, I also have an Item table, the plan is for students or staff to take custody of an item, put in another way, for an Item to have a custodian (student or staff). So I created a new table -- Item_Custodian. How do I model a relationship that would enable my Item_Custodian table holds information about an Item and it's custodian be it a student or a staff. Suggestions, tips etc are welcomed. Thanks
I would share three approaches I know for handling such relationships:
Approache 1: Define two separate nullable foreign keys in
Item_Custodian one referencing to Staff and one referencing to
Student resulting in two physical relationships one of which is
always null.
Approach 2: Define two ranges of Ids for Student and
Staff in a way that don't overlap. Then, create only one column in
Item_Custodian and initialize it with either of the two table Ids
resulting in a logical relationship.
Approach 3: Define two columns in Item_Custodian one as a logical foreign key and the other as the type of the first column (i.e. StaffType or StudentType).
In your scenario where there are only two custodians, I personally prefer the first approach for two reasons:
It creates physical relationship between tables
Only one null column does not make a table sparse
I'm creating a database for personnel records and trying to ease record creation for the user and avoid a kludgy solution. The tables are:
people:
people_id,
person_name,
person_category_id
person_category:
person_category_id,
person type
document_requirement:
document_requirement_id,
document_requirement_name,
person_category_id,
document_section_id
document_section:
document_section_id,
document_section
I've created an append query (inner join) that populates a table caLLed document_repository which contains all of the required documents for all of the people. (I use a primary key composed of people_ID & document_id to avoid duplicates when the append query runs.) Here is the document_repository table.
document_respository:
document_repository_id,
people_id,
person category_id,
document_id,
document_section_id,
document_attachment
I'd like to be able to allow the user to create a document requirement that is applicable to multiple person categories. I understand I should avoid multi field values, which doesn't work anyway with inner joins. For example, if people categories include doctors and nurses, I'd like to be able to create a new document requirement that applies to both people categories (e.g., doctors and nurses), without having to create two separate document requirements.
More information needed?
Suggestions on design changes and/or queries?
Thanks!
snapshot of tables and relationships
What you describe is a many to many relationship. Each document requirement can be applicable to multiple person categories and different document requirements can be applicable to the same person category.
To have a many to many relationship between two entities (tables) in your database, you need another table to relate them. This additional table contains the primary key of both tables and each record in this table represents a link between the two entities.
Your naming is different between your text and your diagram, but I'll assume you want to have document_requirement records that can link to zero or more person_category records.
You need a table which for example could be called document_requirement_person_category and contains the following fields:
document_requirement_id - foreign key referencing PK of document_requirement
person_category_id - foreign key referencing PK of person_category
You then add a record to this link table for each person category that relates to each document requirement.
Edit: BTW, (if I'm reading your schema correctly), you already have a many to many relationship in your schema: document_repository allows a relationship between multiple people and a document requirement as well as multiple document requirements and a person. That's a many to many relationship.
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.
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.
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?