Я провел несколько тестов производительности между Laravel query builder и eloquent. Конструктор запросов был намного быстрее с различными операторами sql (select-update-delete-insert).
Итак, мой вопрос: почему кто-то использует Laravel Eloquent против простого построителя запросов?
Eloquent - это реализация Laravel шаблона Active Record, и он обладает всеми его сильными и слабыми сторонами. Это хорошее решение для использования при обработке одного объекта с помощью CRUD, то есть чтения из базы данных или создания нового объекта, а затем сохранения или удаления. Вы получите много преимуществ от таких черт, как грязная проверка (для отправки SQL UPDATE только для полей, которые были изменены), события модели (например, для отправки административного предупреждения или обновления счетчика статистики, когда кто-то создал новую учетную запись), черт ( временные метки, мягкие удаления, пользовательские черты) нетерпевая/ленивая загрузка и т.д.
Но, как вы уже знаете, это связано с некоторой ценой исполнения. Когда вы обрабатываете одно или несколько записей, вам не о чем беспокоиться. Но для случаев, когда вы читаете множество записей (например, для datagrids, для отчетов, для пакетной обработки и т.д.), Простой DB лучше подходит.
Для нашего приложения мы делаем именно это - используя Laravel Eloquent в веб-формах для обработки одной записи и использования БД (с представлениями SQL) для извлечения данных для сетей, экспорта и т.д.
Да, в некоторых случаях вы правы. Когда у нас есть больше данных и почти на каждом сайте, данные на самом деле не маленькие. Тогда лучше использовать 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:
Итак, наконец-то все ясно: когда мы будем использовать запрос к базе данных и когда мы будем использовать Eloquent Query.
Edit - Пример из реальной жизни
5,000 teachers and 10,000 students and some notices and files. Тогда лучше сделать это с помощью простого Laravel Eloquent, который очень стандартен и удобочитаем.1,000,0000 (1 crore) posts and many more things. Я должен будет выбрать обычные фасады DB там. Это быстрее для поиска сообщений из такого количества записей.Вы можете проверить производительность вашего запроса, используя Laravel Debugbar (популярный пакет для проверки производительности Eloquent/Database Database/времени выполнения)
Теперь это ваш выбор. Что вы хотите сделать...
Почему Laravel Eloquent:
OOP.query builder.table schema. т.е. даже если вы измените имя таблицы, вам не нужно трогать один query (там может быть 1000 query), чтобы он работал. Просто измените имя таблицы в красноречивой model.JOIN, LEFT JOIN, RIGHT JOIN и т.д.) Больше не нужно в запросе для получения данных связанных таблиц.Когда дело доходит до производительности и роста приложения, для сравнения возьмите лут в следующих таблицах:
Сравнение среднего времени ответа операции выбора между Eloquent ORM и Raw SQL
Joins | Average (ms)
------+-------------
1 | 162,2
3 | 1002,7
4 | 1540,0
Result of select operation average response time for Eloquent ORM
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.