I am struggling to figure out the relationship between ingredient and shampoo table. I have a join table between these tables called Shampoo_Ingredients. How do I figure out if these tables would be one-to-one, one-to-many, many-to-one, or many-to-many? Thanks for any help you can provide. This has been a really frustrating concept to me.
Image of DB
A shampoo has many ingredients. An ingredient can be in many different shampoos.
So, you have a many-to-many using a join table Shampoo_ingredients.
Related
Is this a one-to-one or one-to-many relationship?
I think it is one-to-many as one sales rep can serve many customers. But in this select statement case, i am confused.
so I was trying to create an EER diagram from a database model and I wanted to do something similar to this.
Say I have a table named Bag and another one named Address. I already set the PK in Address to be the FK in Bag, when creating the diagram I found that I cannot find the option "many to many" in mySQL workbench.
I wonder what is causing this to happen(maybe I'm doing something wrong but right now I cannot think of any reasonable explanation...)
Hopefully someone can shed some light on this.
Thanks!
Usually many to many relationship would have an additional table to create the relationship -
Address ( table holds addresses )
AddressBag ( tableholds the many to many the bags to addresses relationship with FK to address and FK to bags)
Bag ( table holds the bags )
Many2Many relationship need an additional table to define the relationship between two tables. This table holds the FK to each of the two or more tables. If we want to get the data, just need to select columns by this relationship. Wish this would help you.
I'm new to Access and trying to understand m:m relationships. I understand how to create the junction table containing a composite primary key. What I'm having trouble with is what to do next.
Tbl1 has tbl1PK, Tbl2 has tbl2PK, and JunctionTbl1_2 has J1PK and J2PK. How do I populate JunctionTbl1_2?
If I want to do a query on the records in Tbl1 and Tbl2, do I actually do the query on the junction table?
I'm just a little lost on how to use the table. Any help would be appreciated.
This sounds a lot like this question I answered recently, Multiple Many-to-Many Relationships (Circular Relationship)
See if that answer gives you enough information for what should go in the tables. Once you have the junction (more technically the many-to-many tables) populated, a query to see which products were created by a specific employee would look something like this:
select p_idpk from product_employee as pe where pe.e_idpk = e.e_idpk
Let us know if you need more direction.
I would like to get some opinions since I am thinking about creating structure for my new application and I am struggling with names for tables so I thought maybe you can give me some ideas. App has users and users can create projects while projects can have multiple keywords. So users are in one-to-many relationship with projects and projects are in many-to-many relationships with tags.
So having table users I suppose projects table should be users_projects. But what about keywords? Should it be users_projects_keywords ? And what about pivot table since I think it is kinda bad to name it like users_projects_to_users_projects_keywords or something like that. I would be grateful for a tips.
Edit:
I always thought that one-to-many relationships should be called like x_y where y belongs to x. Is it not a good practice ?
I would have users, projects, keywords, project_keywords. I would use foreign keys to define the relationships between the tables. For example, projects would have a column such as createdby_userid, referring to the users.user_id column.
One idea:
There could be three dictionaries:
Table users should have id and other data.
Table projects as well.
And so table keywords.
Then you create "linking" (relations) tables:
users_projects with column id, id_user, id_project
projects_keywords with id, id_project, id_keyword
EDIT:
Maybe it indeed would be rational to include id_user into table projects as mentioned by #Laurence.
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?