I am using Laravel's ORM model (eloquent), yet this doesn't relate only to Laravel.
I have a Recipe model and I would like to manipulate data on any other model that relates to Recipe, i.e. vitamins, product type, etc (in each recipe). At first I thought it's classic belongsTo Recipe. Yet if, from the vitamins table, each Vitamin shows the range of volume it exists in each Recipe. By this design, doesn't this mean that this relationship is ManyToMany?
Thanks, Bud
To think of "one-to-many" relationship, it defines a single model has many other models. For example, a user can create many recipes. We can say a user has many recipes and a recipe belongs to a user only (but not share with other users).
And "many-to-many" relationship, for example of a relation with recipe with many vitamins, where the vitamins are also shared by other recipes. So we can say a recipe belongs to many vitamins, and a vitamin belongs to many recipe.
Related
I have a Laravel 8 application in which I designed two models, Workspace and Section. Every section belong to a workspace, in a one-to-many relationship.
Both sections and workspaces can have comments; they are implemented in a third model, Comment, with a morphTo relationship. In particular, every comment belongs to a commentable, i.e. a Workspace or a Section.
I'm looking for properly defining a relationship which, from Workspace, allow to retrive all the related comments, i.e. both workspace comments and comments of sections belonging to the workspace.
Can I define somehow this kind of relationship? In particular, I would hypothetically define it a proper way, such that I can use commands like Workspace::with('all_comments') and $workspace->load('all_comments').
Laravel seems not offer a standard interface for defining custom relationships
Thanks,
I am working on a food related Laravel project where I have three main models: RawMaterial, SemiFinished and Finished. A semiFinished object can contain a list of RawMaterial model objects while a Finished object can contain a list of both SemiFinished objects or RawMaterial objects.
I am aware that the solution lies in using polymorphic relationships but I cant seem to get to the right approach.
Please share your ideas on how such a solution would be implemented on both migrations and models/relationships level
Thanks a bunch
You could easily implement your own manual polymorphic relationships on your Finished model. Basically how it works is you will need 2 important fields here, which is the ingredient_id and ingredient_type (change the name to your preference). Then, inside your Finished model, you can make 3 types of relationships, which is ingredients() to get all ingredients regarding the type, semiFinishedIngredients() to get only the semi finished ingredients, and rawIngredients() to get only the raw ingredients. Again, this is optional, add it on your own needs.
Is it okay to use a polymorphic relation when there are lets say 6 common columns and 2 columns with different names?
I need to track car maintenance and refueling.
maintenances - table
-date
-km_driven
-info (refers to maintenance info )
refuelings - table
-date
-km_driven
-amount (refers to amount in liters)
So, should i use polymorphic relationship or not? Is it ok if there are more different columns per model?
IMHO for your case I will go for single table inheritance (STI), but you need a library like this tightenco/parental or this one Nanigans/single-table-inheritance.
Laravel codebase has no support for STI without an external library. You can try to use polymorphic relation to solve your case but you will end up with 3 different tables. I think you want to use a single table with two or even three models so my advice is to try one of the STI library above.
STI is appropriate when your models have shared data/state. Shared behavior is optional because can be defined per Model. An example could be different type of vehicle Models: Car, Truck, Bike etc..
With Polymorphic Relations instead, a model can belong_to several models with a single association. This is useful when several models do not have a relationship or share data with each other, but have a relationship with the polymorphic class. An example could be the Comment Model that can belongs to other Models: User, Post, Image etc..
Using Parse.com "Relations", how do you determine which of the 2 classes should own the Relation?
For example think of WhatsApp groups.
Should User have a relation listing all the groups it subscribes to?
Or should Group have a relation listing all the users in the group?
And, does it make sense to have a relation in each? Duplicating the data?
Depends on if you want to store some metadata in one of the Classes. It is explained quite nicely in this part of the document:
https://parse.com/docs/relations_guide#manytomany-relations
The decision point here is whether you want to attach any metadata to
the relationship between two entities. If you don’t, Parse Relation or
using Arrays are going to be the easiest alternatives. In general,
using arrays will lead to higher performance and require fewer
queries. If either side of the many-to-many relationship could lead to
an array with more than 100 or so objects, then, for the same reason
Pointers were better for one-to-many relationships, Parse Relation or
Join Tables will be better alternatives.
In the whatsapp you have given, Since you have access to user, i think it should be more like what are the groups that user belongs to. Read the many to many relations assuming group as book and users as author. It will make sense
I have a Core Data model and I am trying to figure out how to structure it.
Lets say I have a Recipe. it has a name, title, image and 5 ingredients.
Would I make a recipe entity with recipeName, title. Then an Image entity with recipeName, imageURL.
Then an Ingredient entity with recipename, ingresient1, ingredient1measurwment, ingredient2, etc...
Or would I do it all under a recipe entity (but what happens if theoretically i create a recipe with 100 ingredients?
Also, I use recipeName because I think thats how you link them up?
Based on your question, I would create two different entities.
Recipe,Ingredient
where Recipe has a to-many relationship with Ingredient.
So, Recipe will have some attributes (the attributes you need) and a simple relationship called for example toIngredients. toIngredients is a to-many relationships. In other words, a recipe could have zero (or one if you want) ingredients.
In the same way, Ingredient has some attributes. In addition, it has a to one (inverse) relationship called toRecipe to its Recipe. Here you could decide also to have a to-many if your recipes could share ingredients but it strictly depends on what you want to model.
About rules for relationships, toIngredients has a cascade rule. When you delete a recipe, all its ingredients will deleted too. On the contrary, toRecipe will be of type nullify.
Here a simple schema of it.
where toIngredients is set as follows:
and toRecipe is:
Notice that optional flag for toRecipe is unchecked. This means an ingredient can exists only if a recipe exists. If you don't follow this rule, Core Data will complain about this.
About the image, it depends on how bigger are the images. Follow Marcus Zarra rules for deciding how to design your model Core Data - Storing Images (iPhone).