Eloquent Where ENUM vs Int Foreign Key: Speed Benchmark 

This was fascinating, cheers! I'm a life time member, I'm going to dive into this. Great research!

Thanks, learned that we can also use multiple column indexes!

Thanks, very useful.

Haha, funny to see you doing this experiment too. Few months ago I wanted to experiment using Filament with a huge amount of data, so I cloned the Filament demo and seeded millions of records. The first challenge was to rewrite the seeders and factories in a way that the seeding process doesn't take ages to complete ... 😁 Then I had to optimize some SQL queries, and I noticed the same problem with the deleted_at fields. Had to add some indexes to improve the overall performance.

great work, thank you

At first I thought this was going to be about PHP enums with casts, not sql enums. It might be interesting to dive deeper into the pros and cons of using only PHP enums (design flexibility?) or only sql enums (performance? ) or both. And yeah, it makes sense soft deletes should be a BIG consideration for your use of indexes.

Awesome video

Another option/improvement here is to make a virtual Stored column for `is_deleted`, a tinyint notnull (boolean) that is computed from (deleted_at IS NOT NULL) Then you index that column. You get around the issue with nullable columns, plus your index size is far smaller. It's very seldom you need to check if it was deleted before X date, and those times you can look at the `deleted_at`. But 99% of the time your query is going to be just caring about that boolean value

Good day! Do you have any laravel tutorials that employ this vue3, type script, pinia, and axios?

Hi, Please make a video series on system design video for a Laravel project.

Please make a video for Computed properties in Livewire and be more detailed, like the last video of Josh Cirre in "Which Livewire method should I use?".

I didn’t have the patience to finish watching the video, but I would like to share that every time I heard “tiny int”, my ears screamed in pain. There’s something called padding, and it costs in terms of processing. Padding is bad for performance even if you think l it is just a matter of applying a simple calculation. The problem with it is that processors are much more efficient in loading and transferring data in their “native” block size (and this depends on what operation is being done), generally (today, at least) 64bits. Not “tiny” at all. Add to that, the weak MySQL code base, which, to me, looses only to MS SQL Server.

If not enum, column type varchar and index then ?

It's obviously slower because you did it wrong, you had to make a constant class of statuses (different file for each entity status, for eg TransactionStatus, ShopStatus, etc) instead of saving that on DB

wow