Eloquent or Query Builder: When to Use Which?

I think as a back end developer what is matter is performance and when u are good enough in sql writing queries is a piece of cake . Thanks for this video it is really helpful

I always use eloquent when I modify the data in db like creating or updating. I use Query builder when extracting data in database

Mr. Korop, first of all thank you so much for the videos. You really are a good teacher. Quick question: Im using query builder to fill report data, but when I need to use a related model currency field Laravel casts it as string. If I want the correct casting I need to insert the related field in the casts array of the main model. Is it a good pratice? Shouldnt the cast array content only the model fields? tks in advanced.

Great Video for beginners

Error handling is much easy with eloquent

Thank u

DB::table returns an stdclass so you can't use the model methods

Thanks! Never thought about that difference.

I used the query builder if I didn't need the model. I needed the stdClass object because it was convenient to work with.

Thanks

Hi sir I have a question
Can I pass a veriable in where clause from db like:
Where ('transaction_id', $transaction_id)->get();

You can combine some advantages of Eloquent Builder and both less memory usage like using Query Builder (without hidrate Eloquent models) by using toBase() method of Eloquent Builder.

You are 100 percent correct

you are amazing

You can make table names dynamic when using query builder. So you dont have to update every query when the table name is changing.
$users = DB::table(with(new User())->getTable())->get();
Or you can have a static method in the models, and delegate this logic there and use like this:
$users = DB::table(User::getTable())->get();

In page where need to load alot of information such as dashboard, export to excel, can use Query Builder or Raw SQL. For page such as product page, can use eloquent with paginate so will break the data to small rows althought the the product got 1 millions rows.

What makes laravel special is been able to combine power, performance and ease of use. I know there are other frameworks that perform much better than laravel, but are way much difficult to use.

I use query builder a lot. But only on MySQL VIEWS. This way MySQL can do what it does best, all the heavy lifting.
For normal CRUD, I always use Eloquent.

Please make more video on Laravel Eloquent and try to make Many to many complete crud

Thank you for sharing , this is very intersting.
However, i had to switch from elequent to query builder because it was giving me the wrong results (i'm sure there's a fix that i could'nt find ).
My table has a string id composed of numbers and letters such as 1234M001,
the elequent truncates the id and return only 1234.

thanks

One of the main reasons i use eloquent is events. you forgot to mention that. in lots of situations we cleanup system using eloquent events, like uploaded image files.

hello sir, how about eagerload in query builder with complex syntax?
can you make a tutorial? or can I see in your video which one?

thanks

How we can check API performance? What is better to use for APIs

If we use stored procedure what is the advantage and disadvantage

Wow, thanks, i thought it same as each other

DB all the way with any speed requirements and Eloquent for Crud. We regularly interrogate tables with millions of records and queries were rewritten to use DB for speed. Also that same database imports 100,000 records per day and changing to DB meant we saved 50 percent of the daily load time. However crud, where speed isn't an issue, it's much easier to use eloquent.

Loool What the problem with those people hitting dislike for great tutorials likes this

I've had many situations, where I have had to switch to DB facade. More complicated queries usually tend to be much slower in Eloquent than using the facade or doing raw queries. Eloqent is programmer-friendly.

It is unreal that you managed to hook me into your QAP, but I have to say... I adore your content and I adore your services. Much obliged

Thank you, great content as always. My experience:
1. Simple INSERTS: Eloquent
2. Complex INSERTS: Query Builder
3. Simple READS : Eloquent
4. Complex READS : Query Builder
5. Very Complex READS : Raw SQL

What i miss out for not using eloquent fully is eloquent convenience/magic such as model events. I also find myself not using Eloquent Relationships.

Thanks!

And Also for Example your Clients Company has already have an EXISTING DATABASE SYSTEM they used for so many years, you'll have create to create MODELS for them from scratch if you use Eloquent. i know Eloquent is very easy to use. but this will overshadow one of most important Skills in using SQL, in longer terms this will only dull my senses resulting for many loopholes in my projects.

does it support COMPOUND KEYS?

I'm old school. If I could I would use raw SQL. So, for 90% of my queries I use Query Builder. I have tried to use Eloquent but time and time again, I find myself spending more time searching through the Eloquent docs than writing code especially when it comes to complex queries with multiple joins.

I think eloquent is too magical so I use it in specific cases and thanks for this video

Awesome videos

Eloquent ❤️

With all fairness that QueryBuilder should be in the model too as it has no place in the controller. then you could use $this->table (or self::) and you solved the "rename table" problem without much of a hassle. not as if renaming a table would be a frequent task.
On the other hand this is just ONE query, imagine running twice as slow on every one of them. and eating up 5 times the memory. Yes there are sacrifices on the developer side if you use DB query but keeping your site lightning fast vs "well its easier to read" is not gonna win much fight with the management and with the endusers..
"sure it takes 5 seconds to render, but boy i can read the code with no effort"

i am all in love with Laravel, but performance is key in every application, and running twice as slow quickly adds up. And the issue is that this masquerades the problem so well that less experienced developers will have no idea where the code gets so slow as they expect that laravel is superfast under the hood. (which is true most of the time)
(note : i love automation, and i love that frameworks making life easier and coding faster, and would be super happy to sacrifice some performance, but this example shows that it is not "some" it is a lot. - and i know you can wrap things up and store them in cache for faster access, my point is that with no cache (or empty) things could get dreadfully slow and most of junior / mid devs wont have a clue, and they will accept that pulling 1k of data from a DB is slow, when the truth is DB could handle much bigger datasets much faster)

anyway: keep up the good work, your videos are good and helpful.

If you use some method that that eloquent does not have even if you call it via model facade it falls back to query builder. Like Product::join('products_categories')... so in some sence the diff is really negligible how you access it. $product->category->name or $product->category_name. So its not really an advantage. With our IDEs you can easily find all the cases where you have to change. So one line change versus 20 lines of change its not so different. So we are talking performance vs how quick you can change something for developer. But the probability of this needs changing is very low. So I don't even use eloquent unless it already used and I need to add some stuff.

can you make a video about how make a fast filter and serach method for a very large table?

I have been working with laravel for more than 5 years. Large projects with hundreds of tables. Renaming the output table has never been a task. It's even dangerous. Only in the development process. Therefore, renaming a table in the model is not an argument at all. But everywhere it is indicated as a necessary thing. Wrong.

You can use eloquent for a small project or to read one, a few entries. But the bigger the project, the more pure sql use will pay off more and more.

Mostly I am now writing a clean sql with which I can do whatever I want. Even problems look after "half a year".

$sqlWhere = '';
if (count(ids) > 0) {
$sqlWhere = ' WHERE a IN (' . implode(',', $ids) . ')';
}

$sql = 'SELECT a, b, c FROM table_1 ' . $sqlWhere;

// dump($sql);

$records = DB::select($sql);


There is not much difference for a small number of entries. But huge for many records. And if there is a foreign key - Space rocket.

Thanks for your Video, i want a video from you-> about curd operation (edit), actually how to put old value on combo box, using eloquent and db query both

Excellent advice! Thanks for the hard work.

That's the only reason keeps me away from CodeIgniter 4 which it hasn't relation system.

This varies more if it has a hasMany relationship.

In my local DB table with 1M records the different between query builder (DB::(table_name)->get()) and eloquent model request (Model::all()) is about 7-10% (obviously in favor query builder).