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.
Related
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 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.
Multiple Voting Table Schema:
Single Voting Table Schema:
Businesses, Products, and Comments can all be voted on. For the first obvious solution, I chose to create an association entity for each of the relationships. We thought maybe there would be a better solution, though.
After extensive research and looking around for a solution, I found the concept of the second schema, which is to have a single voting table with a column (Entity) to define the type of the table or the table in which the ID (EntityID being the ID of the Table it Came From) belongs to. The only problem is that there is no relationship between the voting table and the three entities. Is there a way for the Entity Column to refer to the table rather than the table's ID?
Any suggestions of other constructive ways of developing the schema are welcome.
I think you will find this answer very sufficient.
Why can you not have a foreign key in a polymorphic association?
What you're looking at here is a Polymorphic Association. It has many solutions, of which three are described thoroughly through the given post.
I would suggest you combine the Business, Product and Comment tables into a single table, with an additional colume to denote 'Type'. Then you can enforce your relationship to the Vote table.
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 have a table called 'notes', on this table I need to track who made that note, but the problem is that the creator of the note can be a user stored in one of three possible tables:
users
leads
managers
I have though of simply create three fields on 'notes' to represent the three possible relations: note.user, note.lead, note.manager
With this approach I would be forced to create three table joins when requesting the notes to gather the creators information, and I don't think that is the way to go, so I would like to hear your ideas or comments and what would be the best approach on this.
For me personally this smells like a design problem on a totally different part of the schema: Are manageers not users? Do leads carry person information?
With any approach that creates a relation between one column and one of three others, you will need three joins for the select. If you can't rectify the underlying problem, I recommend you use
note_type ENUM('users','leads','managers')
as an additional field and
SELECT
...
IFNULL(users.name(IFNULL(managers.name,leads.name))) AS name
..
FROM notes
LEFT JOIN users ON notes.note_type='users' AND users.id=notes.note_source
LEFT JOIN managers ON notes.note_type='managers' AND managers.id=notes.note_source
LEFT JOIN leads ON notes.note_type='leads' AND leads.id=notes.note_source
...
for the query
I think you need to abstract out the concept of a user id, so that it does not depend on their role. The author of a note could then be specified by the user id.
Users could be assigned roles, and maybe more than one.
The correct way to structure this would be to pull all common data out of users, leads, and managers. Unify this data into a "contact" table. Then if you want to get all notes for a given manager:
managers->contacts->notes
for a lead:
leads->contacts->notes
Notice your original post: "the problem is that the creator of the note can be a user stored in one of three possible tables"
From the structure of your sentence you even admit that all these entities have something in common; they are all users. Why not make the DB reflect this?
you have to model a parent table for the three tables you already have. Define a table that depicts generally user, leads and manager tables. Something like "Person". So you have all of the ids of the three tables and any common attributes on the Person table. And when you must define the relationship you put the foreign id "Person_ID" on the note table. And when you model user, leads and manager tables you also put the primary key as a foreign key to the Person table.
So you would have something like this:
Table users:
Users(
person_id primary key
...(attributes of Users)
foreign key person_id references Person.person_id
)
This model i depict is common to any relational model you have to model using parents and childs