Laravel Eloquent vs query builder - 为什么要使用eloquent来降低性能

I did some performance test between Laravel query builder and eloquent. Query builder was much faster with various of sql statement (select-update-delete-insert).

我在Laravel查询构建器和eloquent之间进行了一些性能测试。使用各种sql语句（select-update-delete-insert），查询构建器的速度要快得多。

So my question is: Why someone uses Laravel Eloquent against plain query builder?

所以我的问题是：为什么有人使用Laravel Eloquent来反对普通查询构建器？

6 个解决方案

#1

Eloquent is Laravel's implementation of Active Record pattern and it comes with all its strengths and weaknesses. It is a good solution to use when you process a single entity in a CRUD manner - that is, read from database or create a new entity and then save it or delete. You will benefit a lot from Eloquent's features such as dirty checking (to send SQL UPDATE only for the fields which have been changed), model events (e.g. to send administrative alert or update statistics counter when someone has created a new account), traits (timestamps, soft deletes, custom traits) eager/lazy loading etc.

Eloquent是Laravel对Active Record模式的实现，它具有所有优点和缺点。当您以CRUD方式处理单个实体时，这是一个很好的解决方案 - 即，从数据库读取或创建新实体，然后保存或删除。您将从Eloquent的功能中受益匪浅，例如脏检查（仅针对已更改的字段发送SQL UPDATE），模型事件（例如，当有人创建新帐户时发送管理警报或更新统计计数器），特征（渴望/延迟加载等时间戳，软删除，自定义特征等

But, as you already know, it comes with some performance price. When you process a single or just a few records, there is nothing to worry about. But for cases when you read lots of records (e.g. for datagrids, for reports, for batch processing etc.) the plain DB is better approach.

但是，正如您已经知道的那样，它带有一些性能价格。当您处理单个或仅几个记录时，没有什么可担心的。但是对于读取大量记录的情况（例如，数据网格，报告，批处理等），普通数据库是更好的方法。

For our application we are doing exactly that - using Laravel's Eloquent in web forms to process a single record and using DB (with SQL views) to retrieve data for grids, export etc.

对于我们的应用程序，我们正是这样做 - 在Web表单中使用Laravel的Eloquent处理单个记录并使用DB（带有SQL视图）来检索网格，导出等数据。

#2

Why Laravel Eloquent:

为什么Laravel雄辩：

1. Executing query in a OOP manner.
2. 以OOP方式执行查询。
3. Easy to use than raw query or query builder.
4. 比原始查询或查询构建器易于使用。
5. No binding with table schema. i.e. Even you change your table name, not need to touch a single query(there may have 1000 query) to make it work. Just change the table name in model.
6. 没有与表模式绑定。即使您更改了表名，也不需要触摸单个查询（可能有1000个查询）来使其工作。只需更改模型中的表名即可。
7. Relationship among tables can be maintain in an elegant way. Just mention the type of relationship, nothing else(JOIN, LEFT JOIN, RIGHT JOIN etc.) needed in query anymore to get data of related tables.
8. 表之间的关系可以以优雅的方式保持。只需提及关系类型，不再需要其他任何内容（JOIN，LEFT JOIN，RIGHT JOIN等）来获取相关表格的数据。
9. Queries highly readable while written using Eloquent comparing with Query Builder.
10. 使用Eloquent与Query Builder进行比较编写时，查询具有高可读性。

#3

Yes, In some case you are right. When we've more data and almost in every site, data is not small really. Then it is better to use DB Query than the Eloquent Query.

是的，在某些情况下你是对的。当我们拥有更多数据并且几乎在每个站点中时，数据确实不小。那么最好使用DB Query而不是Eloquent Query。

In a performance issue of Eloquent VS DB I've heard that,

在Eloquent VS DB的性能问题中，我听说过，

To insert 1000 rows for a simple table Eloquent takes 1.2 seconds and in that case DB facades take only 800 mili seconds(ms).

要为一个简单的表插入1000行，Eloquent需要1.2秒，在这种情况下，DB外观只需要800毫秒（ms）。

So Why then Eloquent ? Is't any necessary of that ?

那么为什么然后滔滔不绝？这不是必要的吗？

Answer is - Eloquent is also necessary. Cause-

答案是 - Eloquent也是必要的。原因-

To create a better relationship and get the results in view with so much simple syntax, when there needs to join.

当需要加入时，创建更好的关系并使用如此简单的语法在视图中获得结果。

Eloquent is also for who have not much knowledge of SQL query.

Eloquent也适用于对SQL查询知之甚少的人。

An MVC framework follow the rules of Code Readability, Code Maintainability and which Eloquent is, you know that. A code comparison below. Obviously, Eloquent is better to read.

MVC框架遵循代码可读性，代码可维护性和Eloquent的规则，你知道。下面的代码比较。显然，Eloquent更好阅读。

// In Eloquent
$student = App\Student::find($id);

// In DB facade
$student = DB::table('student')->where('id', $id)->first();

Most important part is if we want to change other database, then raw query will be a lot much headache to us and in that case Laravel Eloquent will solve all the problems with one hand. It can handle different types Database.

最重要的部分是如果我们想要更改其他数据库，那么原始查询对我们来说将是非常令人头疼的问题，在这种情况下，Laravel Eloquent将一方面解决所有问题。它可以处理不同类型的数据库。

So when we use Eloquent and When DB facades:

所以当我们使用Eloquent和When DB外观时：

1. When we'll work on a simple and small records site with simple CRUD and there records are not fact, then use Eloquent there.
2. 当我们使用简单的CRUD处理一个简单的小型记录站点并且记录不是事实时，那么在那里使用Eloquent。
3. When we'll work on a lot's of records, it is better to use DB Query than Eloquent.
4. 当我们处理大量记录时，最好使用DB Query而不是Eloquent。

So, finally it is cleared that - when we'll use Database Query and When we'll use Eloquent Query.

所以，最后清除 - 我们将使用数据库查询和何时使用Eloquent Query。

Edit - Real Life Example

编辑 - 真实生活的例子

1. I'm making an University website. Which may contain maximum 5,000 teachers and 10,000 students and some notices and files. Then it is better to do this with simple Laravel Eloquent which is very much standard and readable.
2. 我正在建立一个大学网站。最多可包含5,000名教师和10,000名学生以及一些通知和文件。然后最好用简单的Laravel Eloquent来做到这一点，这是非常标准和可读的。
3. Now I'm making a site like *. Which may contains more than 1,000,0000 (1 crore) posts and many more things. I will must choose the conventional DB facades there. It is more faster for searching the posts from so much records.
4. 现在我正在制作像*这样的网站。其中可能包含超过1,000,0000（1千万卢比）的帖子和更多内容。我必须选择传统的DB外墙。从这么多记录中搜索帖子会更快。

Now it's your choice. What you want to make...

现在这是你的选择。你要做什么......

#4

When it comes to performance and the application grows, for the sake of comparison, take a loot at the following tables:

在性能和应用程序增长方面，为了进行比较，请在下表中获取战利品：

Comparison of select operation average response time between Eloquent ORM and Raw SQL

Eloquent ORM与Raw SQL之间选择操作平均响应时间的比较

Eloquent ORM average response time

Joins | Average (ms) 
------+-------------
1     | 162,2 
3     | 1002,7 
4     | 1540,0 

Result of select operation average response time for Eloquent ORM 

---

Raw SQL average response time

Joins | Average (ms) 
------+-------------
1     | 116,4 
3     | 130,6 
4     | 155,2 

Result of select operation average response time for Raw SQL 

Article Reference

文章参考

#5

It is just my opinion, not a comprehensive answer. I use whatever is more convenient in a given situation.

这只是我的意见，而不是一个全面的答案。我在特定情况下使用更方便的东西。

If I come across a package or code written either in eloquent or query builder, I use whatever is being used.

如果我遇到在eloquent或query builder中编写的包或代码，我会使用正在使用的任何内容。

I found query builder to be more intuitive if I create something from scratch so I use it more often.

如果我从头开始创建一些东西，我发现查询构建器更直观，所以我经常使用它。

When it comes to Laravel, it seems, the ease and speed of developing an app is more important then performance. I really like that they make everything very easy even for someone with little prior knowledge of php/mysql. In some cases eloquent is easier than query builder. In others vice versa. I think having many ways of doing something is what makes Laravel so easy and newbie friendly.

谈到Laravel，似乎开发应用程序的简便性和速度比性能更重要。我真的很喜欢他们使一切都变得非常容易，即使对于之前对php / mysql知之甚少的人也是如此。在某些情况下，eloquent比查询构建器更容易。在其他人反之亦然。我认为有很多方法可以让Laravel如此轻松和新手友好。

#6

I like using query builder when building complex query from database because it seems easy to use. For working with a single table, I like eloquent.

我喜欢在从数据库构建复杂查询时使用查询构建器，因为它看起来很容易使用。对于使用单个表格，我喜欢雄辩。