I have 2 tables that needs to be joined wherein both of them can have as many of the other table.
A resident can have as many as relative and the relative can have as many as resident.
I need your opinion if this is a good way to join them properly. What I've done is I have a separate table that saves their respective ids.
I've attached a picture of reference. Thanks!
table picture
Yes, that is a classic relational implementation for a many-to-many relationship, implemented with an intersection table.
Related
I have really dumb question...,
for what are exactly relationships in databases?
If I selecting data from two tables for example:
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;
In query is exactly specified the columns of what tables will be connected to each other.
Result will be same, no matter if I use foreign keys.
Maybe I am not enough good to find answer, but everywhere is explained HOW to use them, but not WHY I should use them.
PS.: Sorry for bad English, google translator did a lot. :)
Relationships in Databases are used to maintain connection between two entities. For example : classes table and Teachers table. a teacher can take more than one class which means there is a one to many relationship here and by separating data into two separate entities help to maintain referential integrity
I work with the MySQL database and I have 2 tables namely vortex and the edge. I provided it below,
Is this one-to-many relationship exists between the tables ? Some explanation will be helpful.
There are two one-to-many relationships because each vertex can be the source or the destination of many edges, but each edge can only have one source and one destination.
Speaking in terms of rows in the tables, you will have each vertex id appearing only once in the vertex table, but potentially more than once in the vertex_src_id and in the vertex_dst_id columns of the edges table.
You have two relation between these tables both one-to-many (one to (one or many ) )
one is based
vertex_src_id
and the second on
vertex_dst_id
I have three tables: Resumes, Orgs, and Resume2Org. Basically, Resume2Org is my many-to-many relationship table linking Resumes.resume_id to Orgs.org_id (so it only has those two keys in that table).
My question is, is it okay to use that many-to-many relationship table to store other data? My use case: the database is part of a system to sift through incoming resumes. But I've been asked to implement a "marked as read" feature so we can easily get the list of resumes we haven't looked at yet. But since a resume can belong to many different orgs, we only want to mark a resume as read for the org the user/viewer belongs to. I thought, hey, having that flag in Resume2Org would be perfect. Is this a smart approach, or should I create a new table specifically for "marked as read"? All the examples I've seen about many-to-many relationship tables is that those tables are used just for that... linking two tables.
Yes it is okey to have additional fields in a many-to-many table. I think it is the right way to do in your case as you don't need to join additional tables and you save spaces.
I was in a very similar situation last week and I added additional field for that.
I have the following tables created:
Animes(id,title,date), Comics(id,title,date), TVSeries(id,title,season,episode,date)
Some of them have already foreign keys (for one-to-many or many-to-many relations) of directors, genres, articles and so on.
Now i would like to create two more tables Reviews(id,rating,date) and Posts(id,thumbid,articleid,reviewid).
A review is about one Anime and/or Comic TVSerie and vise-versa but properties of a review may be in more than one table. Its the same about a posts.
Is this a typical example of one-to-one relation in separate table or is it more efficient to add more properties to the existing tables?
So more tables and relations or less tables more columns?
Thank you and i hope my question isnt that stupid but im a bit confused.
In my view, It is better to avoid foreign key relationship for one-to-one relationship. It is best suitable for one - many relationships.
I'm not exactly sure what your requirements are, but the choices are as follows:
Have Reviews have 2 columns, either being a foreign key to the applicable table, can be NULL. This is really for when a single review can be about both.
Have a ReviewsComics and ReviewsAnime table. You'd then have all the fields from Reviews in each table (and no Reviews table).
An alternative (2) is to use them in conjunction with a Reviews table, then those 2 tables only has 2 fields which are foreign keys to Reviews and Comics/Anime respectively (thus no direct link between Reviews and Comics/Anime).
Have a base table to which Anime and Comics are linked to 1-to-1 and have reviews link to that table instead.
(Edit) If all the fields are all going to be the same (or similar) for Anime/Comics, you can merge them into a single table and add a type field, indicating Anime/Comics, then the problem goes away. This is similar to the base table option.
EDIT: The 2 reviews tables will probably give the best performance (unless you want to select all reviews for either, often), but with proper indices the performance shouldn't be an issue with any of the above.
I'm thinking about merging different many to many relationships in a single table and I would like to know if you think that's smart.
Here are two examples with two separate "relationships" tables:
table: products
table: product_categories
table - relationship table: link_products_product_categories
another example:
table: users
table: user_categories
table - relationships table: link_users_user_categories
Do you think it is smart to create a single table called for example "relationships", which would have fields like this:
first_field_table: users
second_field_table: user_categories
first_field_id: 2
second_Field_id: 5
or
first_field_table: products
second_field_table: product_categories
first_field_id: 3
second_field_id: 5
That would require some changes in my framework, but it would mean a lot less tables. Do you think that's a good idea to store all these relationships in a single table and identify both tables with fields or is it better to keep them separate and have more tables?
"..but it would mean a lot less tables.."
Many tables is not a bad thing per se. Your solution should have as many tables you need as long as you follow the rules of database normalization.
And to answer your question, no It's not good. Infact It's really bad! All it does is cause huge confusion.
Simple answer no it is not smart.
What is the problem with having lots of tables?