In addition to 1:many, many:many, and many:1 (which is just 1:many but looking at it in the other direction), you also occasionally see 1:1, for example if you want to augment a table with additional data. This might be done by having your foreign key also be your primary key in the augmenting table, since that would also enforce a uniqueness constraint on the FK as a result.

Also, probably unnecessary to mention, but you can also have “0 or 1” relationship (meaning one side is optional but capped at 1). These are technically separated from “1” relationships usually when you get into all the theory. An example of this might be a “0:1” relationship using the above augment table, but where the augmenting table isn’t required to have a row for every row in the augmented table. (A 1:1 constraint can be enforced, for example, by having an additional FK in the augmented table pointing to the augmenting table.)

Laravel’s documentation does a very good job of describing these types of relationships. Even if you’re not a PHP developer, their docs cover the basics.

many2one: so in this relationship you will have more than one record in one table which matches to only one record in another table. something like A <– B. where (<–) is foreign key relationship. so B will have a column which will be mapped to more than one record of A.

no, the other way around

When B has a foreign key to A, many B records may relate to one A record. That’s the many2one part.

The fact that different B records can point to different A records is irrelevant to that.

one2many: same as many2one but instead now the foreign key constrain will look something like A --> B.

It’s the same, mirrored. Or mirrored interpretation / representation to be more specific. (No logical change.)

If you had B --> A for many2one, then the foreign key relationship is still B --> A. But if you want to represent it from A perspective, you can say one2many - even though A does not hold the foreign keys.

In relational database schemata, using foreign keys on a column means the definition order is always one to one, and only through querying for the shared id will you identify the many.

many2many: this one is interesting because this relationship doesn’t make use of foreign key directly. to have this relationship between A and B you have to make a third database something like AB_rel. AB_rel will hold values of primary key of A and also primary key of B. so that way we can map those two using AB_rel table.

Notably, we still make use of foreign keys. But because one record does not necessarily have only one FK value we don’t store it in a column but have to save it in a separate table.

This association table AB_rel will then hold the foreign keys to both sides.

You also have NoSQL databases, where you can have arrays, embedding and you can often save yourself the CPU hit of joins.