Laravel Eloquent 与 DB 外观：为什么使用 Eloquent 并降低性能？ [关闭]

Eloquent 是 Laravel 对 Active Record 模式的实现，它具有所有优点和缺点。

Active Record 是以 CRUD 方式处理单个实体的一个很好的解决方案——也就是说，创建一个具有填充属性的新实体，然后将其保存到数据库、从数据库加载记录或删除。

您将从 Eloquent 的功能中受益匪浅，例如脏检查（仅针对已更改的字段发送 SQL UPDATE）、模型事件（例如，当有人创建新帐户时发送管理警报或更新统计计数器）、特征（时间戳、软删除、自定义特征）急切/延迟加载等。您还可以应用域驱动模式并在 Active Record 实体中实现一些业务逻辑，例如验证、管理关系、计算等。

但是，正如您已经知道的那样，Active Record 带有一些性能价格。

当您处理单个记录或几条记录时，无需担心。但是对于读取大量记录的情况（例如，对于数据网格、报告、批处理等），普通的 Laravel DB 方法是一种更好的方法。

对于我们基于 Laravel 的应用程序，我们正在使用我们认为合适的两种方法。我们使用 Laravel 的 Eloquent for UI 表单来处理单个记录，并使用 DB 方法（由 SQL 视图支持，并带有额外的数据库引擎特定的性能调整）来检索 UI 表的数据、导出任务等。它也适用于 RESTful API - Eloquent 用于 GET、PUT、POST、DELETE 与键和 DB 用于 GET 没有键但具有过滤器和排序和分页。

---

是的，在某些情况下你是对的。

当您处理更多数据时，最好使用 Laravel 的 DB 外观查询构建器，而不是 Laravel 的 Eloquent ORM。

从性能测试来看，在一个简单的表中插入 1000 行需要 Eloquent 1.2 秒，而 DB 门面只需要 800 毫秒。

那么为什么要使用 Eloquent 呢？口才也很重要，因为：

它的语法比 DB 外观更简单。

对于不懂 SQL 的开发人员来说更容易。您需要了解 SQL 才能使用 DB 门面。

使用 Eloquent 编写的代码比使用 DB 外观编写的代码更具可读性和可维护性： // With Eloquent $student = App\Student::find($id); // 使用 DB 门面 $student = DB::table('student')->where('id', $id)->first();

如果你想更改数据库，使用 Laravel Eloquent 会更容易，因为它可以处理许多不同的数据库，而 DB 门面需要你编写 SQL，这可能需要为不同的数据库重写。

因此，当您在一个小型站点上使用简单的 CRUD 操作时使用 Eloquent，当您使用 Eloquent 不支持的许多连接和其他功能时使用 DB 外观。

现实生活中的例子：

你正在制作一个大学网站，其中包含 5,000 名教师和 10,000 名学生，以及一些通知和文件。使用 Laravel Eloquent 构建这个站点会更好，因为它简单易读。你正在制作一个像 Stack Overflow 这样的高流量网站，它每月为超过 1 亿人提供服务，并拥有超过 7000 万个帖子。最好使用 DB 外观，因为它更快，并且会显着加快响应时间。

您可以使用 Laravel Debugbar 检查查询性能。

Here 是 Eloquent 和 DB 门面之间的性能、内存消耗和代码质量的完整比较。

---

为什么使用 Laravel Eloquent 而不是 DB 门面：

您可以编写面向对象的代码。它比编写原始 SQL 或使用 DB 外观更容易使用。没有绑定到表模式，所以例如如果你想改变你的表名，你不必触及单个 Eloquent 查询，只需更改 Eloquent 模型中的表名。可以以优雅的方式维护表之间的关系。只需提及关系类型（JOIN、LEFT JOIN、RIGHT JOIN 等）即可从相关表中获取数据。 Eloquent 查询比原始 SQL 或 DB 外观更具可读性。您可以在模型内部使用方法、范围、访问器、修饰符等，这是一种可维护的模式。

---

当谈到性能和应用程序增长时，为了比较，请查看下表：

Eloquent ORM 平均响应时间：

平均连接数（毫秒） 1 162.2 3 1002.7 4 1540.0

原始 SQL 平均响应时间：

平均连接数（毫秒） 1 116.4 3 130.6 4 155.2

Article Reference

---

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

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

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

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

---

Eloquent ORM 最适合在特定表中处理较少的数据。另一方面，查询构建器在处理一个或多个表中的大量数据时花费的时间比 Eloquent ORM 更快。

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

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

---

他们之间有很多不同

生成器查询比您通过调试器测试的 ORM 快得多。这是测试 https://scotch.io/tutorials/debugging-queries-in-laravel 的方法。当您处理大量数据时，构建器查询的执行时间更少，例如数据库中的数据比 ORM 多 1,00,000。 Builder 查询最适合大量数据。Orm 最适合使用关系，因为它提供了许多关系方法来定义表之间的关系。生成器查询使用 sql 的连接，但 orm 使用关系来处理 2 个表或更多表。

---

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

---