I have two different models in two different PostgreSQL tables for which there's a relationship with objects in a third table. Objects in the third table can only be linked to one object in one of the other tables (think of the two tables as pictures and posts and the other table as comments).
I only need to read from these tables, I never have to add objects in them. I have also nearly no control over the way the tables are defined.
How would I setup this relationship in SQLALchemy so that I can query posts or pictures with their associated comments ?
Related
Maybe better as DBA question...
We have a Laravel/MySQL system. We have 4 model types that are also tables, Categories, Stars, Studios and Videos. Contractors set up pivot tables for each of these model types to house multiple many-to-many relationships to each other. The pivot tables are categoryables, studioables and videoables. These each contain the same structure (categoryables as an example):
id, category_id, categoryable_type ('App\Models\Video'), categoryable_id (ID of model type), created_at, updated_at
The current model types we have in each of those pivot tables are:
Categoryables: Star, Studio and Video
Studioables: Star
Videoables: Star, Studio
My questions are:
I know Laravel's pivot table naming convention is normally like category_video, so is appending "able" also a proper naming convention?
Are these even pivot tables, or are they called something else considering they're set up to have multiple data model types, eliminating a simple relationship of just two tables?
What is the best way to house our data for multiple many-to-many relationships? Each model type has a page on our front end, ie. going to a category shows a list of stars, studios and videos. Going to a studio shows a list of categories, stars, and videos, etc. There are 4 possible set ups I can think of:
3a. videoables table is all we use and it has relationships to
stars, studios and videos model types.
3b. We use categoryables, starables and studios only (calling them
category_video, star_video, studio_video) and each of them only has
a relationship to the video model type.
3c. We use all 4 pivot tables and they each contain all of the
relationships to the other 3 model types. This seems like a lot of
bloat and redundancy.
3d. Somewhere in between 3b and 3c. Some sort of perfect combination
of relationships that enhances query speed and performance without
suffering from table bloat and redundant data.
Thanks!
A many-to-many relationship needs an extra "mapping" or "junction" table. ("Pivot" may be used here, but is confusing since it has an unrelated meaning relating to transposing between rows and columns.)
Details on optimal implementation of a Many-to-many table. (I do not know whether Laravel is efficient here.)
Yes, it sometimes makes sense to have a table with 3 ids instead of just 2.
For further discussion, please provide the CREATE TABLEs of one 2- or 3-way relationship table.
I have two Tables in PowerBI with Many to Many Relationship, I need to find the exact count of the rows from both the tables (after adding filters) which are in same visualization table.
Image showing Relationship between tables
I have 3 tables, User, AccessControlKey and AccessControlGroup. User can be assigned to multiple products. AccessControlKeys can be assigned to multiple AccessControlGroups. However a User cannot have AccessControlKey assigned to him more than once i.e. for a User across the multiple AccessControlGroups assigned to him, AccessControlKey has to be unique across the AccessContolGroups assigned to him.
For the many to many relationships between accesscontrolkeys and user and for many to many relationship between accesscontrolkeys and accesscontrolgroups i have two separate tables. Following is the table descriptions for the 3 tables and the relationship mapping table. How do i enforce the unique AccessControlKey across multiple AccessControlGroup for a User?
http://pastebin.com/EzL9QUGg
From your description, I'm guessing that each User has one AccessControlKey and the key can belong to multiple AccessControlGroups.
I'd probably change the data structure and change your User_BelongsTo_AccessControlGroup to a User_AccessControlKey (linking a User to an AccessControlKey) instead; you can enforce the uniqueness here. You can still get to the User's AccessControlGroups through this table and the AccessControlKey_BelongsTo_AccessControlGroup.
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 want to know in what situations we create many to many relation. What is the need of doing such?
A quick search goes a long way. Though the following is for MS Access, the concept is the same for any relational database.
Via: office.microsoft.com - Create a many-to-many relationship:
You have a many-to-many relationship when a single record in one table
can relate to many records in another, and a single record in that
second table can also relate to many records in the first. For
example, say your company has several types of computers and several
technicians, with each technician certified to work on some, but not
all, of the computers. Each technician can be related to more than one
computer, and in turn, each computer can be related to more than one
technician.
To track who can work on a given machine, you create a many-to-many
relationship by adding the primary keys from both sides of the
relationship to a third table, called a junction or link table. In
other words, a many-to-many relationship is really just a pair of
one-to-many relationships.