If you want to find more about DB structure and how to use it in Eloquent, I have a full 4-hour course "Eloquent: Expert Level": laraveldaily.teachable.com/p/laravel-eloquent-expert-level
This is very controversial, but the question is: where the enum into the DB come from? The old times DBA used to store lists of values into integer fields into the DB since forever because relations were (and are) expensive. I worked around 2003 on a DB of an university in which this pattern was extensively used. If it is good or wrong depends entirely by your problem domain. If you know very well your problem domain and you know that the data you want to put into the enum will not change during time, the enum is the right choice, it will occupy only 2 bytes. This is also better than have a VARCHAR field in which you store the value (this is another alternative to ENUMs), which will use 1 or 2 bytes plus the string length. On the PHP side you have to abstract every enum element into constants value and use them instead of the strings directly, as showed in this video (remember: if you use a constant, you only need to change that constant instead of do a global search and replace to fix the code when using explicit strings). When your problem domain models data which is subject to change or needs to change in the future, even if you have at first few values go with a relation. The problem, as said, with relations is that they are expensive and you always need to have a field with a slug that let you use a string constant instead of a number (the primary key) to reference a value in the enum relational table and make your code future proof.
You can always use a config option as well, it is faster to implement and no need for a join. Saves a table but uses a little(very little) more memory for your config. Also you can always add a comment for that column to specify that the values are coming from a config file. In a project with a lot "states" you could save lets's say up to 10 tables. When you have 10 tables for data and 10 for states I think a config option is better.
I use enums combined with the myclabs/php-enum package and am very happy with it. I use explicit getters in my models that instantiate an enum object from the database value and use that value object with handy tools built in (ofcourse you can also use custom cast classes or accessors/mutators). I also use dynamic predicates in the base enum class which is very conventient for comparisons e.g. $enum->is{EnumValueInStudlyCase}() which does an internal equals check if given enum value exists.
I'm having my custom enum base class and I create separate classes for each enum but I'm planning to use spatie Laravel enum package after it's latest release. Spatie enum is expected to release major version within few weeks. Bensampo enum is also interesting, I'll have a try with that package.
I feel like you're my personal mentor. I picked up a few different coding principles and "Must Do" coding styles and understandings from other Laravel developers over my time. But watching your videos, have definitely helped me grow as a developer and code much more cleaner/efficiently now. Thank you!
@@PovilasKorop Is more then one appreciate what you doing for all of us, so we just to lazy to tell about it =) But believe! Your mission is veery important to all. Thank you! I hope in the future you will focus more on teach ppl to the right way.
I think enums are quite useful on those parameters that are not changed frequently and are not that important to deserve a relation. I’m working on a project where enum is used to define the type of content: content N, category C, tag T
God to know! By meh "problem" - better compare pure query vs database wrappers... when why etc... cos i dont think some one will suffer because of int instead enum )
I'm using enumeration case I have static choices to pick a one from it ,but if you want to edit the blues you have to change in too many locations of the code !
I don't think it is rare that a developer has to look at the database. I prefer looking at the database all the time to actually figure out the problem as the database is the source of truth. This is even required when you have to maintain a source code from other developers or an outsource company.
I have a similar setup for languages: I have name,level where level is a enum(['basic','intermediate','advanced']). I think I should switch it to foreign key implementation
Why not set values in config and then use it for const and in migrations with enum so you always change in 1 place and it's also readable in DB. Creating table for 3 const options is a mess in my opinion. Enum is easier to debug also for new devs that join so they don't have to guess "what value that int has" while working in DB. Of course it depends on app, if you change values 5 times a week [in prod], then sure go for table. Also I think that making enum (making list) is just more logical for non editable static options.
What's your perspective on using a json column for meta data ? Recently while working on a project found myself refering to woocommerce for their structure of data they use for orders and found that they have a column for meta data, not sure if its a json o an extra table with the primary key, key name and value structure, but since I needed to figure out a way to query orders and bring along 4 posible types of dispatch options which have quite different sets of values thought that creating 4 extra tables to accomodate such endevour was over kill. Would love some other points of view on the subject. Thank you
I use it inside the model: public const STATUS_OPEN = 1; public const STATUS_IN_PROGRESS = 2; public const STATUS_CLOSED = 3; const TICKET_STATUS = [ self::STATUS_OPEN => 'This ticket is being processed', self::STATUS_IN_PROGRESS => 'This ticket is in progress', self::STATUS_CLOSED => 'This ticket has been closed', ]; public function getStatus() { return [ 'id' => (integer)$this->status, 'description' => self::TICKET_STATUS[$this->status] ]; } This way I can do verbal things like: Ticket->setStatus(Ticket::STATUS_IN_PROGRESS);
i use this method myself but im wondering wouldnt it be risky though if ever there will be a change in the numbers in the future and you somehow forgot to change it?
I think some of the arguments against enums are not valid.. it's like how many times do u add/change enums? And u can still have const on your model.. I use fk but I find the argument a bit indigenous
If you want to find more about DB structure and how to use it in Eloquent, I have a full 4-hour course "Eloquent: Expert Level": laraveldaily.teachable.com/p/laravel-eloquent-expert-level
This is very controversial, but the question is: where the enum into the DB come from? The old times DBA used to store lists of values into integer fields into the DB since forever because relations were (and are) expensive. I worked around 2003 on a DB of an university in which this pattern was extensively used. If it is good or wrong depends entirely by your problem domain.
If you know very well your problem domain and you know that the data you want to put into the enum will not change during time, the enum is the right choice, it will occupy only 2 bytes. This is also better than have a VARCHAR field in which you store the value (this is another alternative to ENUMs), which will use 1 or 2 bytes plus the string length. On the PHP side you have to abstract every enum element into constants value and use them instead of the strings directly, as showed in this video (remember: if you use a constant, you only need to change that constant instead of do a global search and replace to fix the code when using explicit strings).
When your problem domain models data which is subject to change or needs to change in the future, even if you have at first few values go with a relation. The problem, as said, with relations is that they are expensive and you always need to have a field with a slug that let you use a string constant instead of a number (the primary key) to reference a value in the enum relational table and make your code future proof.
You can always use a config option as well, it is faster to implement and no need for a join. Saves a table but uses a little(very little) more memory for your config. Also you can always add a comment for that column to specify that the values are coming from a config file. In a project with a lot "states" you could save lets's say up to 10 tables. When you have 10 tables for data and 10 for states I think a config option is better.
for dealing with status, i think the best is use package spatie/laravel-status, which use fk with only one table for every model
I use enums combined with the myclabs/php-enum package and am very happy with it. I use explicit getters in my models that instantiate an enum object from the database value and use that value object with handy tools built in (ofcourse you can also use custom cast classes or accessors/mutators). I also use dynamic predicates in the base enum class which is very conventient for comparisons e.g. $enum->is{EnumValueInStudlyCase}() which does an internal equals check if given enum value exists.
I'm having my custom enum base class and I create separate classes for each enum but I'm planning to use spatie Laravel enum package after it's latest release. Spatie enum is expected to release major version within few weeks. Bensampo enum is also interesting, I'll have a try with that package.
I feel like you're my personal mentor. I picked up a few different coding principles and "Must Do" coding styles and understandings from other Laravel developers over my time. But watching your videos, have definitely helped me grow as a developer and code much more cleaner/efficiently now. Thank you!
Did you buy some course from the author? There is much more usefull info 4 sure!
@@qAntBcn I actually haven't yet. But I'm planning to. He definitely knows his stuff and I can tell he's a great teacher too.
Thanks for kind words, Darren, it motivates me to continue with my "mission".
@@PovilasKorop You're welcome!!
@@PovilasKorop Is more then one appreciate what you doing for all of us, so we just to lazy to tell about it =) But believe! Your mission is veery important to all. Thank you! I hope in the future you will focus more on teach ppl to the right way.
I think enums are quite useful on those parameters that are not changed frequently and are not that important to deserve a relation. I’m working on a project where enum is used to define the type of content: content N, category C, tag T
God to know! By meh "problem" - better compare pure query vs database wrappers... when why etc... cos i dont think some one will suffer because of int instead enum )
I'm using enumeration case I have static choices to pick a one from it ,but if you want to edit the blues you have to change in too many locations of the code !
I don't think it is rare that a developer has to look at the database. I prefer looking at the database all the time to actually figure out the problem as the database is the source of truth. This is even required when you have to maintain a source code from other developers or an outsource company.
What about tiny integer with values like 0,1,2,3 etc. for this situation?
Foreign keys look up table with an extra column for label
there is a way to get enum types immediately from db would't this solve the issue
Thanks you for the video
I've got enum for "monthly/quartely/yearly" payment period
I have a similar setup for languages: I have name,level where level is a enum(['basic','intermediate','advanced']). I think I should switch it to foreign key implementation
I agree 💯!
Why not set values in config and then use it for const and in migrations with enum so you always change in 1 place and it's also readable in DB. Creating table for 3 const options is a mess in my opinion. Enum is easier to debug also for new devs that join so they don't have to guess "what value that int has" while working in DB. Of course it depends on app, if you change values 5 times a week [in prod], then sure go for table. Also I think that making enum (making list) is just more logical for non editable static options.
What's your perspective on using a json column for meta data ? Recently while working on a project found myself refering to woocommerce for their structure of data they use for orders and found that they have a column for meta data, not sure if its a json o an extra table with the primary key, key name and value structure, but since I needed to figure out a way to query orders and bring along 4 posible types of dispatch options which have quite different sets of values thought that creating 4 extra tables to accomodate such endevour was over kill.
Would love some other points of view on the subject. Thank you
I'm not a fan of json columns in general, but will add to my to-do list to shoot some video about it in the future.
I use it inside the model:
public const STATUS_OPEN = 1;
public const STATUS_IN_PROGRESS = 2;
public const STATUS_CLOSED = 3;
const TICKET_STATUS = [
self::STATUS_OPEN => 'This ticket is being processed',
self::STATUS_IN_PROGRESS => 'This ticket is in progress',
self::STATUS_CLOSED => 'This ticket has been closed',
];
public function getStatus()
{
return [
'id' => (integer)$this->status,
'description' => self::TICKET_STATUS[$this->status]
];
}
This way I can do verbal things like: Ticket->setStatus(Ticket::STATUS_IN_PROGRESS);
i use this method myself but im wondering wouldnt it be risky though if ever there will be a change in the numbers in the future and you somehow forgot to change it?
What IDE do you use for laravel?
Phpstorm
I think some of the arguments against enums are not valid.. it's like how many times do u add/change enums? And u can still have const on your model.. I use fk but I find the argument a bit indigenous
thank you for this .. keep going
No need to convince me 👍