Best way to relate two tables

@MurilloGoulart's answer is correct but only to be more complete ...

In systems analysis, a many-to-many relationship (also abbreviated as N for N or N: N) is a type of cardinality that refers to the relationship between two entities A and L in which A can contain a parent instance for which there are many child instances in L and vice versa.

For example, thinking of A as Authors and L as Books, an Author can write several Books and a Book can be written by several Authors.

In a relational database management system, such relationships are usually implemented through an associative table (also known as a join table or crosstab). For example, an AL table having two one-to-many relationships A → AL and L → AL. In this case, the logical primary key for AL is made up of two foreign keys (that is, copies of the primary keys of A and L). " Wikipedia

Basically, in many-to-many relations, or N to N, a third table is created where the Foreign Keys (FK) of the other two tables are stored, but not only that, just like the others have a unique key (primary key)

When the relationship can not have the combination of foreign keys repeated

For example, a book may have several authors, which may have several books but there will never be a same author referencing the same book twice, in these cases the index can be formed by the union of the columns, the command can change accordingly with the SQL language

In cases where there may be two lines with the same combination of FK

A practical example (which I was taught) is a video store where it has a movies table and a customers table, where a customer can rent one or more movies and the movies can be rented by one or more customers, noting that one has several units of the same film

Another column is created which will be the primary key for this table / relation:

   filmes_clientes      filmes     clientes
 +-----+-----+-----+    +-----+    +-----+
 | pk  | fk1 | fk2 |    | pk1 |    | pk2 |
 +-----+-----+-----+    +-----+    +-----+
 |  0  |  1  |  0  |    |  0  |    |  0  |
 +-----+-----+-----+    +-----+    +-----+
 |  1  |  1  |  0  |    |  1  |    |  1  |
 +-----+-----+-----+    +-----+    +-----+

Another option is to use another column that saves the date

If for some reason this relationship will be saved also the date it occurred can use the same to create the unique key, for example:

           filmes_clientes                filmes     clientes
 +-----+-----+-----------------------+    +-----+    +-----+
 | fk1 | fk2 |          data         |    | pk1 |    | pk2 |
 +-----+-----+-----------------------+    +-----+    +-----+
 |  1  |  0  |  2018-04-30 16:05:00  |    |  0  |    |  0  |
 +-----+-----+-----------------------+    +-----+    +-----+
 |  1  |  0  |  2018-04-30 16:05:01  |    |  1  |    |  1  |
 +-----+-----+-----------------------+    +-----+    +-----+

But be careful in these cases, imagine a store that has branches where a person rented a movie with his user and his partner rented the same movie with the same user at the same time, difficult to happen (even more in a video store) but it can happen and generate conflict. Of course you can also put beyond the date, the branch where the movie was rented, but there already are two extra columns that maybe not even used, they are only there to avoid duplication, so a PK in the table originated from the relation N: N

    

Need to have an intermediate table to make relationship N: N:

Table groups_roles :

+----------+---------+
| id_group | id_role |
+----------+---------+