Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi.
Recently I joined a company. the project that my team is maintaining and developing is made by Lumen. but they haven't used Eloquent. they query the database using Laravel query builder.
As I see it, the queries are awful. but when I talked to them and asked them why they have avoided Eloquent, they said that Eloquent queries are not efficient. they said Eloquent is slow and there are a lot of joins in Eloquent queries.
They have the same opinion about all ORMs like NHibernate and Entity Framework.
Is that right? How can I check the difference? How can I check eloquent queries on Lumen?
it depends query to query - eloquent builds query in some way but in terms of efficiency sometimes is join better sometimes is subquery better and maybe they found that their queries built by eloquent would have opposite one what i think they didn't maybe they just thinks thats the case this is up to you to ask them
but i have to say eloquent is completely fine unless their db got higher millions of rows
They didn't even use The Active Record design pattern.
They have 3 classes: Repositories, Factories, Entities.
Repository makes the sql query, then passes the result to Factory, then Factory maps the result to entity and returns the entity.
I thought maybe there is some technical architectural reason behind this! but when I found out that they haven't heard of Active Record design pattern, I thought maybe these are all mistakes, made because of lack of knowledge.
Am I looking at this in a wrong way? or this is just a bad architecture?
Have you seen this Repository-Factory-Entity pattern somewhere else?
Why not test it out. Run one of their queries 1000 times in a loop and then the eloquent equivalent a 1000 time, and compare timing
Debugbar makes this easy
measure('old query', function() {
// Do something…
});
measure('eloquent query', function() {
// Do something…
});
You can also use debugbar to compare number of queries in a single run with execution time
@kiasaty Anyone saying Eloquent is "slow" doesn't really know what the tool is capable of. I just had this conversation with another business unit at my company... basically they didn't want us using the ORM because it is slow and inefficient... which isn't true at all.
Install Telescope. You can find slow queries with this... most of the time using with() in Eloquent will avoid the need for joins and N+1 queries.
I demonstrated this to the other business unit and they were like "oh, ok... wow, yeah, that's really cool".
Eloquent can be SLIGHTLY slower... but you're talking microscopic fractions of a second. Not enough of a justification not to use it.
I think Eloquent uses wherein to query relation not join. I use Eloquent when a query is simple, and the DB facade for a complex query. To each their own
Like everything when it comes to SQL you need to write good code. A badly written query is slow regardless if it's done in Eloquent, Query builder or just plain SQL.
As a rule of thumb I use Eloquent if the query is not that complex like a simple select with a where and order by clause.
$records = Record::where('aritst_id', 1)->orderBy('title')->get();
If I need to join more than two tables together I usually push the query into the database so I can still use Eloquent in my controller.
In the example below the Artist, Genre and Format table is joined in the view in the database.
$records = RecordView::where('artist', 'Run Dmc')->orderBy('title')->get();
The biggest reason I don this is that I'm more comfortable with SQL than Eloquent and like to keep my eloquent queries KISS.
Eloquent converts to regular SQL at runtime. So it's a moot point.
Active record is a shortcut for you, not database manipulation. Otherwise it would be a language in itself.
A good example https://laracasts.com/discuss/channels/laravel/sql-native-to-query-builder
If that was done in eloquent it would convert it right back to the regular SQL.
they said that Eloquent queries are not efficient.
Eloquent uses the query builder under the hood…?
they said Eloquent is slow and there are a lot of joins in Eloquent queries.
Only if you write queries with joins.
Repository makes the sql query, then passes the result to Factory, then Factory maps the result to entity and returns the entity.
Well that’s wrong. A repository itself is supposed to return entities. Factories are being used entirely wrong there.
@kiasaty It sounds like your colleagues couldn’t be bothered to learn how to use Laravel/Lumen and Eloquent properly, and instead hand-rolling their own solutions with incorrectly-used design patterns.
Eloquent uses the query builder under the hood…?
True, but eloquent query Builder and DB facade all use regular PDO under the hood. Regular SQL with regular bindings. Active record does some of the work for you, but you have to watch raw statements, there bindings does not automatically happen.
If you really want to learn this stuff study the api.
Or see how Taylor did things in the vendor folder.
See the warning here https://laravel.com/docs/6.x/queries#raw-expressions
@sinnbeck Thanks man. I'm gonna test it. it would be the best if Telescope supported Lumen.
@fylzero with() is a good idea. I'm gonna use it in my projects. it goes well with /authors?include=books for example.
what are the bullet points to explain in these situations? they are not gonna be convinced but at least i'm gonna try.
Active record is a shortcut for you, not database manipulation.
@jlrdw All the factory classes that they have made would be unnecessary if they had used Active Record.
It sounds like your colleagues couldn’t be bothered to learn how to use Laravel/Lumen and Eloquent properly
Yeah. they didn't know Laravel well when they started coding. even now. even validations are not the way they're supposed to be.
instead hand-rolling their own solutions with incorrectly-used design patterns.
When I go through the code, I think I'm looking at pure PHP.
It blew my mind when I found out that the product manager is against defining foreign keys on tables. he says it slows down the queries and everything should be handled in code not in db. is that right?
#region //some code #endregion
@martinbean I don't know how to make principles like SOLID second nature in a team that whether don't know them or are against them :\
It's a big project and a lot of people are using it across the country. when somewhere in code is changed bugs appear in other places. I merge new features with shaking hands :)(
Probably unnecessary anyway.
They could probably work out using Repository with models and controllers.
But even patterns are for us humans.
The patterns are meaningless at runtime and to the CPU.
Even when I programmed Java, I stuck with regular classes (ejb's), servlets, and JSP pages. Somehow it all worked without adding in a bunch of other patterns.
Those factories and repositories could also be done in plump models. But a lot of folks do not like plump models.
I usually just like sticking with regular MVC.
But in a way they are correct eloquent has many good uses but don't forget it is not for everything.
And sometimes it will not be as efficient.
For example monthly accounts receivable reports I'd use regular PDO every time.
Just some of my thoughts on it.
P.S. eloquent and hibernate isn't really a comparison. Hibernate is closer to Doctrine ORM.
Browse over the documentation for both and you'll see what I mean.
@kiasaty I don’t want to sound mean, but it sounds like you’re working with a bunch of absolute amateurs and you’re not going to learn anything in this company.
I lie. You will learn: bad habits.
Please or to participate in this conversation.