Laravel Eloquent против построителя запросов - зачем использовать eloquent для снижения производительности

Почему Laravel Eloquent:

• Выполнение запроса с помощью OOP.
• Прост в использовании, чем необработанный запрос или query builder.
• Нет привязки к table schema. т.е. даже вы меняете имя таблицы, не нужно касаться одного query (может быть 1000 query), чтобы заставить его работать. Просто измените имя таблицы в model.
• Отношения между таблицами можно поддерживать элегантным способом. Просто укажите тип отношения, больше ничего (JOIN, LEFT JOIN, RIGHT JOIN и т.д.), Необходимые в запросе, чтобы получить данные связанных таблиц.
• Запросы, хорошо читаемые при написании с использованием Eloquent по сравнению с Query Builder.

Да, в некоторых случаях вы правы. Когда у нас есть больше данных и почти на каждом сайте, данные на самом деле не маленькие. Тогда лучше использовать DB Query, чем Eloquent Query.

В проблеме производительности Eloquent VS DB я слышал, что

Для вставки 1000 строк в простую таблицу Eloquent требуется 1,2 секунды, и в этом случае фасады БД занимают всего 800 миль (мс).

Так почему тогда красноречивый? Разве это не нужно?

Ответ - красноречивый также необходим. Cause-

Чтобы создать лучшие отношения и получить результаты с таким простым синтаксисом, когда нужно присоединиться.

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.

Edit - Пример из реальной жизни

1. Я делаю сайт университета. Который может содержать не более 5,000 teachers and 10,000 students and some notices and files. Тогда лучше сделать это с помощью простого Laravel Eloquent, который очень стандартен и удобочитаем.
2. Сейчас я делаю сайт наподобие Stackoverflow. Который может содержать более 1 1,000,0000 (1 crore) posts and many more things. Я должен будет выбрать обычные фасады DB там. Это быстрее для поиска сообщений из такого количества записей.

Теперь это ваш выбор. Что вы хотите сделать...

Когда дело доходит до производительности и роста приложения, для сравнения возьмите лут в следующих таблицах:

Сравнение среднего времени ответа операции выбора между 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 

Ссылка на статью

Это просто мое мнение, а не всеобъемлющий ответ. Я использую все, что удобнее в данной ситуации.

Если я сталкиваюсь с пакетом или кодом, написанным либо в красноречивом, либо в построителе запросов, я использую все, что используется.

Я обнаружил, что построитель запросов более интуитивно понятен, если я что-то создаю с нуля, поэтому чаще использую его.

Когда дело доходит до Laravel, похоже, легкость и скорость разработки приложения важнее производительности. Мне очень нравится, что они делают все очень просто даже для тех, у кого мало знаний о php/mysql. В некоторых случаях красноречивый проще, чем построитель запросов. В других наоборот. Я думаю, что иметь много способов сделать что-то, что делает Laravel настолько легким и дружелюбным к новичкам.

Мне нравится использовать построитель запросов при создании сложного запроса из базы данных, потому что он кажется простым в использовании. Для работы с одной таблицей мне нравится красноречивый.

Eloquent ORM лучше всего подходит для работы с меньшим количеством данных в конкретной таблице. С другой стороны, построителю запросов требуется меньше времени для обработки многочисленных данных, будь то в одной или нескольких таблицах быстрее, чем в Eloquent ORM.

В моем случае я использую ELoquent ORM в приложении с таблицами, которые будут содержать менее 17500 записей. Всякий раз, когда я ожидаю, что таблица будет содержать более 17500 записей, лучше всего подходит построитель запросов.

Кроме того, в приложениях с подзапросами я предпочитаю построитель запросов, а не ELoquent ORM.