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.
Related
I have a Laravel 8 application and am wondering how to solve the problem of how to solve a typical polymorphic issue. I have an Employee model. That Employee can be an ExecutiveEmployee or EntryLevelEmployee. There will be methods an ExecutiveEmployee has that an EntryLevelEmployee doesn't have and the inverse is also true.
Using Laravel 8, is it right to create a base Employee model (without a corresponding table?) and then create two models named ExecutiveEmployee and EntryLevelEmployee that inherit from Employee? This would also imply that both employee types will have two different database tables, even though there will be a lot of overlapping data.
Does it make sense to just have one Employee model and create a migration that has the employee type listed in the model? I am assuming that it's ok if an EntryLevelEmployee has some database attributes which are relevant to it that may or may not be relevant to an ExecutiveEmployee type here, or is that an incorrect assumption?
What's the correct way to model this in Laravel 8? I prefer to keep everything in one table because of how similar the models are. I do have to keep in mind that there will be data that one has that the other doesn't. There will be different accessor methods as well.
Is it possible to have everything in one employees table while utilizing multiple models? Meaning, if I create two models named ExecutiveEmployee and EntryLevelEmployee they would both query the underlying table employees?
UPDATE 1
The more I research, the more I think polymorphism is the incorrect approach here and what I might need is Single-Table Inheritance. This package seems to bring the capability to Eloquent. Would there be a good reason to not use this?
I would use polymorphic relationships in this case, because you are more flexible and have less coupling.
Using the Single Table Inheritance (STI), you can add type specific columns in the employees table and make them nullable. But think about adding/removing types in the future.
executive_employees
id - integer
executive_specific - string
entry_level_employees
id - integer
entry_level_specific - string
employees
id - integer
name - string
email - string
employable_id - integer
employable_type - string
As for the STI the same would be
employees
id - integer
name - string
email - string
type - string
executive_specific - nullable string
entry_level_specific - nullable string
So STI would be suitable when you don't have type specific columns. But you want to add specific behavior in your code. For example a User type (Admin, Author).
Even so, it's a matter of preferences.
It really depends on the state and behavior of your employee object.
Below are few points I will consider to make a decision
If your objects' states/properties are different then definitely you will create different models as your data will be stored in different tables.
If most states/properties are same and some are different, you can
consider storing all in one table/model and for the difference in
behavior create separate table like Ron Van Der Heijden has
suggested and you can consider query scope with that to make
transaction with database.
And another view will be
How many JOINs you will create if you will create different tables,
will that impact the performance and other stuffs, will it make your
code complex?
Can you make simpler relations and handle stuffs independently?
When you are making an API, will your
code make the api overworking? or you need to create too many request
for any operation?
These stuffs will decide how you will make a decision.
Update 1:
Another point I would like to add about the package you are thinking to use, consider using a parent key in table and you can define relationships in a single model.I do not think you need to use a package, you can define it yourself, I guess.
I don't understand why you don't create a simple one-to-many relation. Based on the information you provided, the polymorphic relation looks unnecessary. I think the right way is to create employee_roles table and relations. Then you can give different permissions to different employee types. There are several ways to do that. You can create a middleware to create route restrictions. You can check the role before executing a function in the controller, and run only if the employee has permission. You can use if-else in blade not to render the parts that can't be used by auth user etc.
If you have different “types” of employees, and each employee type should have different logic then yeah, that sounds like a polymorphic relationship.
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..
I currently do have a vehicles table that holds "Cars".
Now I want to allow the system to have Bikes, Cars and Trucks.
They have some fields in common (manufacturer_id, mileage, ... ) but they also have specific fields (Bike: cylinder_capacity, seats; Car: doors, ...)
I have tried using all columns in vehicles table and then use the models to handle the differences, But i had problems setting the fillable fields for the child models...
Then I read about polymorphic relations and it seems the right way to go.
So, my questions are: Which approach is the best? What is the best way to implement it?
Thanks!
Create additional tables:
vehicles_types to store types, like cars, bikes etc.
vehicles_attributes to store specific type attributes related via vehicle_type_id with fields vehicle_type_id, name, value.
I extend other models occasionally, and it works as expected. The migrations need to be set up separately, but the class logic (attributes and methods) will work in the normal OOP way. If you're familiar with this, just do what you're doing!
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.
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).