6mo ago

understanding many2one, one2many and many2many relationshit

Hii,

I am new to database thing so I am trying to wrap my head around it.

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.
one2many: same as many2one but instead now the foreign key constrain will look something like A --> B.
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.

tell me if I got something wrong :) give me some suggestion <3

12 comments

Usually we don't distinguish between many2one and one2many, since it's the same just viewed from the other entity.
There is one more class though, which is one2one. That is, the entities have a direct relationship. Sometimes this also includes the case where you have zero or one, i.e. the relation is optional on one side. This can be accomplished with an FK plus unique constraint or by merging the tables.

One to many: my primary key is other table’s foreign keys.
Many to one: other table’s primary key is my foreign keys.
Many to many: my primary key and other table’s primary key are all foreign keys that connect each other in some other table.
So yeah, you’ve got it right. :)
- This is probably the most straightforward explanation. In many-to-many, I usually have a helper table standing in between which holds the foreign keys

I find real-world examples help grasp concepts for me. I'll use an example like a video platform (like Youtube) as an example for this:
One-to-one: for each one User, you maybe only allow one [content] Channel (or, could be one-or-none, meaning a User may have one Channel, or may use use their User account to be a viewer and have no Channel. You might decide to change this later to be one-to-many, but for the example let's say you don't). All the data could be stored just on the User entity, but maybe you decided to separate it into two tables so you don't need to query the User entity which has sensitive info like a password, email, or physical address, when you just need a Channel. For each Channel, there is a foreign key pointing to the (owning_)user_id, and this is "unique", so no duplicate id's can exist in this column.
One-to-many (or Many-to-one): for each one Channel, there may be many Videos. You could use a relational table (channel_x_video), but this isn't necessary. You can just store the (owning_)channel_id on the Video, and it will not be unique like the prior example, since a Channel will have many Videos, and many Videos belong to one Channel. The only real difference between "one-to-many" and "many-to-one" is semantic - the direction you look at it.
Many-to-many: many Users will watch many Videos. Maybe for saving whether a Video was watched by a User, you store it on a table (by the way, this example might not be the best example, but I was struggling to find a good example for many-to-many to fit the theme). Although each video-to-user relation may be one-to-one, many Videos will be watched by one User, and many Users will watch one Video. This would be not possible to store on both the Video or the User tables, so you will need a relational table (video_x_user, or include "watched" in the table name for clarity of purpose). The id column of each row is irrelevant, but each entry will need to store the video_id and the user_id (and neither will be unique), as well as maybe the percent watched as a float, the datetime it was watched, etc. Many-to-many relationships get very complicated often, so should be used carefully, especially when duplicate combinations of a_x_b can occur (here, we shouldn't store a new row when a user watches a video a second time)
- Thank you for the in depth explanation. It improved my understanding of relationship between tables and the YouTube example was awesome😊
- Another Many-to-many example within this usecase would be "subscriptions". Users can subscribe to multiple channels and channels can have multiple users subscribed to them. You would use another relational table that stores the channel_id & user_id, with uniqueness for both together, since "being subscribed to one specific channel multiple times" doesn't make sense and perhaps put a column to store "hitting the bell" in there too.

to have this relationship between A and B you have to make a third database
Probably just a mistake here, but you make a third table, not a new database.
Apart from that (and the fact that one to many and many to one is the same thing), yeah, looks correct.

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.

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.)

You also have NoSQL databases, where you can have arrays, embedding and you can often save yourself the CPU hit of joins.
- I am familiar with NoSQL databases. they are generally easy to use and don't require much effort. however we use postgresql where I am doing my internship. It's a Odoo based company and Odoo uses postgresql as backed database.

12 comments