Laravel Eloquent vs查询构建器 - 为什么要使用eloquent来降低性能

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

要为一个简单的表插入1000行,Eloquent需要1.2秒,在这种情况下,DB外观只需要800毫秒(ms).

那么为什么那么雄辩呢？这不是必要的吗？

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

要建立更好的关系,并与这么多简单的语法得到的结果看,当有需要加入.

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

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

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

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

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

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

1. 当我们使用简单的CRUD处理一个简单的小型记录站点并且记录不是事实时,那么在那里使用Eloquent.
2. 当我们处理大量记录时,最好使用DB Query而不是Eloquent.

所以,最后清除 - 当我们使用数据库查询时,我们将使用Eloquent Query.

编辑 - 真实生活的例子

1. 我正在建立一个大学网站.哪个可能包含最大值5,000 teachers and 10,000 students and some notices and files.然后最好用简单的Laravel Eloquent来做到这一点,这是非常标准和可读的.
2. 现在我正在制作像Stackoverflow这样的网站.哪个可能包含多个1,000,0000 (1 crore) posts and many more things.我必须选择传统的DB外墙.从这么多记录中搜索帖子会更快.

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

Answer 3

为什么Laravel雄辩:

1. 以某种OOP方式执行查询.
2. 易于使用比原始查询或query builder.
3. 没有约束力table schema.即使你改变你的表名,也不需要触摸一个query(可能有1000个query)来使它工作.只需更改表中的名称即可model.
4. 表之间的关系可以以优雅的方式保持.只需提及关系的类型,JOIN, LEFT JOIN, RIGHT JOIN查询中不再需要任何其他(等)来获取相关表的数据.
5. 使用Eloquent与Query Builder进行比较编写时,查询具有高可读性.

Answer 4

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

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

雄辩的ORM平均响应时间

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

Result of select operation average response time for Eloquent ORM 

原始SQL平均响应时间

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

Result of select operation average response time for Raw SQL 

文章参考

Answer 5

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

如果我遇到用 eloquent 或查询构建器编写的包或代码，我会使用正在使用的任何内容。

我发现如果我从头开始创建一些东西，查询生成器会更直观，所以我会更频繁地使用它。

对于 Laravel，似乎开发应用程序的简便性和速度比性能更重要。我真的很喜欢它们让一切变得非常简单，即使对于那些对 php/mysql 知之甚少的人来说也是如此。在某些情况下，eloquent 比查询生成器更容易。在其他情况下则相反。我认为有很多做某事的方法是让 Laravel 如此简单和新手友好的原因。

Answer 6

Eloquent ORM 最适合处理特定表中的较少数据。另一方面，查询生成器处理大量数据所需的时间更少，无论是在一个还是多个表中，速度都比 Eloquent ORM 更快。

就我而言，我在一个应用程序中使用 ELoquent ORM，该应用程序的表将容纳少于 17500 个条目。每当我预计表将容纳超过 17500 个条目时，查询构建器都是最好的。

此外，在带有子查询的应用程序中，我更喜欢查询构建器而不是 ELoquent ORM。