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.
Related
I'm no MySQL expert and I have to design a rather complex db for my level.
The problem I'm facing now consist in having a supplier-customer relationship within the same table (macro categories of companies):
Macro table
id name mega_id macro_customer_id
------------------------------------------
1 Furniture 2 2,4,5,35
I want to represent the fact that macro entry with id 1 has other macro companies (which are their customers) described within the same table.
Which is the best way to represent this?
Thanks!
It depends: We all used to use the normalization forms (as #1000111 indicated), however depending on the use of the data, you can choose to look different at certain parts of this normalization discussion:
The normal model for this would be:
Table userData(id,name)
- 1:N table linkTable(id,macro_customer_id)
- N:1 table metaData(macro_customer_id,value)
Or:
Table userData(id,name)
- 1:N table linkTable(macro_customer_id,id)
The big question is however in how the data is used. If data is just for this user and not queried in any other way (no where, or group by), then storing it as a serialized String is a completely valid approach.
The relationship between entities in an RDBMS should be stored in a relational way. Ask yourself if you care about this relationship in your database - will you need to write queries that will link macro.id to table/rows represented by IDs in macro.macro_customer_id? If yes, then you must store this relationship in a (one-to-many or many-to-many) separate table.
I'm finding the best way to convert an eer diagram to the corresponding relational diagram. I have a generalization entity with some specializations which have separate relationships with other entities. The generalization entity has in turn a n-to-m relationsip with an entity. The following drawing clarifies the situation:
Eer diagram with specialization and n-to-m relationship.
As the two specialized entities have separate relationships, I should convert them to two separate tables. Meanwhile, I should create a table modeling the n-to-m relationship which relates the entity 'User' to the entity 'Newsletter' (or better, its specializations). How to cope with this problem? I've not found any useful information.
The only possible solution I thought to was to create two separate tables modeling the n-to-m relationship, one linked to 'User' and 'Programming newsletter' tables, one linked to 'User' and 'Travel newsletter' tables. But I'm looking for opinions for that.
I see no problem. I would implement your diagram using the following tables:
User (nickname PK, name, address)
Newsletter (name PK, supervisor, type)
Subscription (user_nickname PK/FK, newsletter_name PK/FK)
Programming_Newsletter (newsletter_name PK/FK, type FK, language)
Travel_Newsletter (newsletter_name PK/FK, type FK, means_of_transport)
I probably wouldn't use user nicknames / newsletter names as keys since I prefer stable compact identifiers, but that's another topic.
I think there are a couple of ways to go about this.
The simplest one, would be to break the assumption "As the two specialized entities have separate relationships, I should convert them to two separate tables". If you keep your specialisations together in a single table, you can use STI (Single table inheritance) for your generalisation. This approach has a drawback though, which is that your table will have many NULL values for those relationships that do not belong to the concrete specialisation.
The other approach, would be to use CTI (Class Table Inheritance). This approach assumes that there will be a specific table for each specialisation of your generalisation. This would get around the NULL problems, but it can potentially introduce a performance problem due to the fact that your code will need to eagerly join from the generalisation table to the specialisation on almost every single query you make to retrieve them.
I don't quite see the issue in the n-to-m relationship between User and Newsletter. You should be able to have a regular intermediate table that creates the association between the two, since there are no further attributes that complement that relationship.
The following is an Entity Relationship of a a Baseball League.
I'm having a bit of confusion understanding Relations and Attributes of Relations.
An description of the diagram follows:
According to the description, Participates is a Relation and Performance is an Attribute (complex) of Participates.
Questions:
How do Participates Map to actual tables in a database?
Would there be a Participates table with the fields that define Performance?
{Hitting(AtBat#, Inning#, HitType, Runs, RunsBattedIn,
StolenBases)}, {Pitching(Inning#, Hits, Runs, EarnedRuns, StrikeOuts, Walks, Outs, Balks, WildPitches)}, {Defense(Inning{FieldingRecord(Position,
PutOuts, Assists, Errors)})}
Similarly are Plays_For, Away_Team and Home_Team also tables.
As you create tables in a database (say MySql) how are Relations differentiated from Entities / Objects like Player, Team and Game.
Thanks for your help.
Question 1: Participates would be an actual table with foreign key columns for Player and Game as well as the column(s) for Performance. All M-N relationships need to be modelled in a separate table.
Question 2: To keep it as a semi-decent relational DB you would have to separate all the info into separate columns so that each column would only hold one singular data. If you didn't separate the data you would break the first normal form and would probably run into problems later in the design.
Question 3: As these three are 1-N you could also implement them with columns on the N-side. In the Game table for example you could have two foreign keys to Team table as well as all the data about the relationships in columns. For claritys sake you could make those relationships as separate tables also. As a sidenote: are you sure Player-Team is a 1-N-relationship so that a if a player changes teams the history-info about the StartDate and EndDate of the previous team is immediately lost?
Question 4: They are all treated absolutely the same - no differentiation.
I was studying about relationships in RDBMS.I have understood the basic concept behind mapping relation ship,but I am not able to spot them.
The three possibilities :
one to many(Most common) requires a PK - FK relationsip.Two tables involved
many to many(less common) requires a junction table.Three tables Involved
one to one(very rare). One table involved.
When I begin a project,I am not able to separate the first two conditions and I am not clear in my head.
Examples when I study help for a brief moment,but not when I need to put these principles in to practice.
This is the place where most begineers falter.
How can I spot these relationships.Is there a simpler way?
Don't look at relationships from a technical perspective. Use analogies and real-life examples when trying to envision relationships in your head.
For example, let's say we have a library database.
A library must have books.
M:M
Each Book may have been written by multiple Authors and each Author may have written multiple Books. Thus it is a many-to-many relationship which will reflect into 3 tables in the database.
1:M
Each Book must also have a Publisher, but a Book may only have one Publisher and a Publisher can publish many Books. Thus it is a one-to-many relationship and it reflects with the PublisherId being referenced in the Books table.
A simple analogy like this one explains relationships to their core. When you try to look at them through a technical lens you're only making it harder on yourself. What's actually difficult is applying real world data scenarios when constructing your database.
I think the reason you are not getting the answers that you need is because of the way you are framing the question. Instead of asking “How do I spot the correct type of relationship between entities”, think about “How do my functional needs dictate what relationship to implement”. Database design doesn’t drive the function; it’s the functional needs that drive the relationships you need to implement.
When designing a database structure, you need to identify all the entities. Entities are all the facts that you want to store: lists of things like book titles, invoices, countries, dog species, etc. Then to identify your relationships, you have to consider the types of questions you will want to ask your database. It takes a bit of forward thinking sometimes… just because nobody is asking the question now doesn’t mean that it might not ever be asked. So you can’t ask the universe “what is the relationship between these lists of facts?” because there is no definitive answer. You define the universe… I only want to know answers to these types of questions; therefore I need to use this type of relationship.
Let’s examine an example relation between two common entities: a table of customers and a table of store locations. There is no “correct” way to relate these entities without first defining what you need to know about them. Let’s say you work for a retailer and you want to give a customer a default store designation so they can see products on the website that their local store has in stock. This only requires a one-to-many relationship between a store and the customer. Designing the relationship this way ensures that one store can have many customers as their default and each customer can only have one default store. To implement this relationship is as easy as adding a DefaultStore field to your Customer table as a foreign key that links to the primary key of the Store table.
The same two entities above might have alternate requirements for the relationship definition in a different context. Let’s say that I need to be able to give the customer the opportunity to select a list of favorite stores so that they can query about in stock information about all of them at once. This requires a many-to-many relationship because you want one customer to be able to relate to many stores and each store can also relate to many customers. To implement a many-to-many relationship requires a little more overhead because you will have to create a separate table to define the relationship links, but you get this additional functionality. You might call your relationship table something like CustomerStoreFavorites and would have as its primary key as the combined primary keys from each of the entities: (CustomerID, StoreID). You could also add attributes to the relationship, like possibly a LastOrderDate field to specify the last date that the customer ordered something from a particular store.
You could technically define both types of relationships for the same two entities. As an example: maybe you need to give the customer the option to select a default store, but you also need to be able to record the last date that a customer ordered something from a particular store. You could implement the DefaultStore field on the Customer table with the foreign key to the Store table and also create a relationship table to track all the stores that a customer has ordered from.
If you had some weird situation where every customer had their own store, then you wouldn’t even need to create two tables for your entities because you can fit all the attributes for both the customer and the store into one table.
In short, the way you determine which type of relationship to implement is to ask yourself what questions you will need to ask the database. The way you design it will restrict the relational data you can collect as well as the queries you can ask. If I design a one-to-many relationship from the store to the customer, I won’t be able to ask questions about all the stores that each customer has ordered from unless I can get to that information though other relationships. For example, I could create an entity called "purchases" which has a one-to-many relationship to the customer and store. If each purchase is defined to relate to one customer and one store, now I can query “what stores has this customer ordered from?” In fact with this structure I am able to capture and report on a much richer source of information about all of the customer's purchases at any store. So you also need to consider the context of all the other relationships in your database to decide which relationship to implement between two particular entities.
There is no magic formula, so it just takes practice, experience, and a little creativity. ER Diagrams are a great way to get your design out of your head and onto paper so that you can analyze your design and ensure that you can get the right types of questions answered. There are also a lot of books and resources to learn about database architecture. One good book I learned a lot from was “Database System Concepts” by Abraham Silberschatz and Henry Korth.
Say you have two tables A and B. Consider an entry from A and think of how many entries from B it could possibly be related with at most: only one, or more? Then consider an entry from B and think of how many entries in A it could be related with.
Some examples:
Table A: Mothers, Table B: Children. Each child has only one mother but a mother may have one or more children. Mothers and Children have a one-to-many relationship.
Table A: Doctors, Table B: Patients. Each patient may be visiting one or more doctors and each doctor treats one or more patients. So they have a many-to-many relationship.
An example of one to one:
LicencePlate to Vehicle. One licence plate belongs to one vehicle and one vehicle has one licence plate.
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.