1. Describe 1VS1 relationship
For example, two tables, a departmental table, a manager's table, a department with only one manager, and a manager who controls only one department, which expresses a single relationship
Class User extends Eloquent {
One
Public Function Dept () {
return $this->hasone (' Dept '); This matches the eloquent model
}
Class Dept extends Eloquent {
Public Function User () {
return $this->belongsto (' user '); This matches the eloquent model
}
We can conclude that in a one-to-one relationship, the main table (that is, the table that did not save the user_id table), with Hasone, another table, save the user_id, with the Belongsto to express. In other words, when we see a table with Blongsto, if there are no parameters, it means that the table is associated with the previous table using the method name _id
2.1vs Multi-Relationship description
For example, Class table, Student table, a class has many students, a student is only in one class, so the class table with student table is one-to-many relationship
Class Squad extends Eloquent {
One-to-many
Public Function student () {
return $this->hasmany (' Student ');
}
Class Student extends Eloquent {
Public Function Squad () {
return $this->belongsto (' Squad ');
}
We can conclude that in a one-to-many relationship, the main table (that is, the table that does not save the squad_id table), with Hasmany, another table, save the squad_id, with the Belongsto to express.
3. Describe many-to-many relationships
For example, a role table, a user table, a role with multiple users, a user can have multiple roles
Class Role Extentds eloquent{
Public Function user{
return $this->belongstomany (' Role ', ' user_role ');
}
}
PS: In fact, we do not have to write in our model so many of the things that may be confusing to us, but only when we need to make certain queries to write, for a simple example, if we only need to look at the number of users of a role, and we find that the role and the user is a many-to-many relationship, We can write a user method in the role table. If we need to look up all the students in a class, we find that the class is a one-to-many relationship with the students, and we can write the student method in the class model and use the Hasmany.
We don't have to mess up these things. Our thinking, all according to the actual needs, need to query, then think about the relationship, and then write the method. For example, I want to check the user of a role, we have to understand the role and the user is a lot of relationship, will naturally use the blongstomany, rather than we invented in a vacuum.