if there is one scenario in which we may have to implement Mongo DB in future instead of mysql database currently we have in our project. then, what should be the preferred way to write all queries using Eloquent or Using Query Builder. Can you please create a video with all the pros and cons of both and how we use different database when we needed by just changing database type
I build a web app for a client and it was a requirement to fetch all the questions ( 10K+ ) from the database (No pagination, No Ajax ... nothing) it was a requirement to get all the data at once. There can be many cases when you need to query much bigger data then you think.
10000 is relatively very small number. Let's say your site grow by millions and you have a query which joins six or seven table (which usually happens) then Eloquent won't work that well because of not optimized query.
@@FaizanAnwerAli "Eloquent won't work that well" .. you think? You're right. It will suck, it will crash your app. Be a real programmer, learn SQL, use it. (not speaking directly to you because you obviously already know this, just trying to get people to realize they should not use the ORM for everything).
that is a good one , but why all the heap about eloquent , i mean performance is every thing, can i sacrifice the performance in exchange of having flexible object in eloquent way
Performance is hardly everything. Most of the SMEs won't reach a point where the data they have becomes a bottleneck for the application. So what do you get with eloquent? Development speed. Use the right tool for the job always.
@@juanpadilla8760 Lol, "Performance is hardly everything". You go and tell that to the corporations that have hired me to come in and fix their scripts that ran for hours by converting the ORM/Eloquent/Doctrine junk to Raw SQL. After those conversions, the scripts ran in milliseconds instead of hours. Every time. Use the right tool for the job. Always. For databases of any significant size and complexity, that tool is SQL, or at least Query Builder - not these Active Record, or Entity, or Dapper ORMs.
@@ShabbeyRoadMusic I'm not sure what's your point, I agree that in the case of corporations that may not be the right tool for the job, but SMEs make up 99.8% of all the businesses in Europe... As I mentioned, more often than not the queries to run are not extremely complex and the volume of users is rather low in those cases. And with limited resources, development speed can make it or break it.
@@juanpadilla8760 Point taken, Juan. But I always think about how a database might scale up when I'm developing. If a developer has confidence a SME won't become a BBVA or a Marfeel, then it's fine to go the easy & quick route.
Optimized eloquent will perform just slightly slower (almost unnoticeable) and a bit more "expensive" than query builder, but eloquent comes with uncompromised advantages like maintainability and scalability for future developments... That's why a company will always want eloquent as they need to see the future, not just the "current speed" which is historically proven will always be boosted by the technologies themselves (php, mysql, server, networking, etc.) over the time... So be wise developer... Cheers
Well, for an actual library software, none of the examples would work. You would need complex SUID (CRUD) stored procedures (selects with input parameters) behaving like a table. You can not select directly from table(s) it is impossible to make such software like that. You can not manipulate the data outside the database except for a small resultset. By the way, book title and author are two properties out of more than a thousand and most of them are repeatable (ie multiple authors). And also "where title like %a%" is not usable, you have to search for every criteria (property) and for every word of search and for values in book and then combine results (some may have more than 100 thousand hits) with intersection.
if there is one scenario in which we may have to implement Mongo DB in future instead of mysql database currently we have in our project.
then, what should be the preferred way to write all queries using Eloquent or Using Query Builder.
Can you please create a video with all the pros and cons of both and how we use different database when we needed by just changing database type
If you want total abstraction bewteen models and persistence, use Doctrine in Laravel instead of Eloquent.
have you posted the results somewhere. so i can look at them
No one said about stored procedure why?
How will it be laravel attendance Integration shift wise?
What's difference between query builder and elequent please explain me in brief
In query builder you can fetch data from database by using DB .
But if you go with eloquent model then u have to create model to fetch data
what about "sql no cache"?
How to get the in-browser console laravel?
It's Laravel Debugbar: github.com/barryvdh/laravel-debugbar
Sir, can you explain, wchich better for use in project for security and performance....
May I know which tool you are using for query log?
Laravel Debugbar, if that's what you meant by "query log".
@@PovilasKorop yes. Excatly. Thanks
laraveldaily.com not working
Thank you, fixed.
@@PovilasKoropthanks. ))
Hi!! Which chrome addon you are using for this video?
It's not a chrome addon, it's Laravel Debugbar package
10,000 book at same time , who gonna query that btw . and you did not print result on test 2 and 3 so i think that effect results .on prccess.
haven't seen that done anywhere
I build a web app for a client and it was a requirement to fetch all the questions ( 10K+ ) from the database (No pagination, No Ajax ... nothing) it was a requirement to get all the data at once. There can be many cases when you need to query much bigger data then you think.
@@chasadurrehman2306 but you can always use laravel chunk to get the data in chunks instead of fetching all the records
10000 is relatively very small number. Let's say your site grow by millions and you have a query which joins six or seven table (which usually happens) then Eloquent won't work that well because of not optimized query.
@@FaizanAnwerAli "Eloquent won't work that well" .. you think? You're right. It will suck, it will crash your app. Be a real programmer, learn SQL, use it. (not speaking directly to you because you obviously already know this, just trying to get people to realize they should not use the ORM for everything).
This is really interesting. What columns do you have indexes on for these queries?
Don't remember now, to be honest, I don't think I added any indexes, except for the ones automatically added with foreign key columns.
@@LaravelDaily It would be interesting to run the same query, but with the name column indexed for Elloquent.
that is a good one , but why all the heap about eloquent , i mean performance is every thing,
can i sacrifice the performance in exchange of having flexible object in eloquent way
Performance is hardly everything. Most of the SMEs won't reach a point where the data they have becomes a bottleneck for the application.
So what do you get with eloquent? Development speed.
Use the right tool for the job always.
@@juanpadilla8760 Lol, "Performance is hardly everything". You go and tell that to the corporations that have hired me to come in and fix their scripts that ran for hours by converting the ORM/Eloquent/Doctrine junk to Raw SQL. After those conversions, the scripts ran in milliseconds instead of hours. Every time. Use the right tool for the job. Always. For databases of any significant size and complexity, that tool is SQL, or at least Query Builder - not these Active Record, or Entity, or Dapper ORMs.
@@ShabbeyRoadMusic I'm not sure what's your point, I agree that in the case of corporations that may not be the right tool for the job, but SMEs make up 99.8% of all the businesses in Europe... As I mentioned, more often than not the queries to run are not extremely complex and the volume of users is rather low in those cases.
And with limited resources, development speed can make it or break it.
@@juanpadilla8760 Point taken, Juan. But I always think about how a database might scale up when I'm developing. If a developer has confidence a SME won't become a BBVA or a Marfeel, then it's fine to go the easy & quick route.
thank you...
what editor are you using?
PHPStorm.
thanks
I always prefer query builder, but interviewer always stick with the eloquent.
Same with me 😃
Optimized eloquent will perform just slightly slower (almost unnoticeable) and a bit more "expensive" than query builder, but eloquent comes with uncompromised advantages like maintainability and scalability for future developments...
That's why a company will always want eloquent as they need to see the future, not just the "current speed" which is historically proven will always be boosted by the technologies themselves (php, mysql, server, networking, etc.) over the time... So be wise developer... Cheers
yung db query builder when getting data with relationship is much better
Its more readable
SPOILER
Eloquent: 0.5 sec
SQL Builder: 0.05 sec
Its not thuth challenge.
Getting different result in each test.
Well, for an actual library software, none of the examples would work. You would need complex SUID (CRUD) stored procedures (selects with input parameters) behaving like a table. You can not select directly from table(s) it is impossible to make such software like that. You can not manipulate the data outside the database except for a small resultset. By the way, book title and author are two properties out of more than a thousand and most of them are repeatable (ie multiple authors). And also "where title like %a%" is not usable, you have to search for every criteria (property) and for every word of search and for values in book and then combine results (some may have more than 100 thousand hits) with intersection.
your macbook is trotlinng )))) xDDDD thats why eloquent stucks
This is why Eloquent model has Eager Loading , look into it
That is eager loading. What's your point?
Dont fight