Laravel Eloquent проти конструктора запитів - Навіщо використовувати eloquent для зниження продуктивності [closed]

Я провів перевірку продуктивності між розробником запитів Laravel та красномовним. Конструктор запитів був набагато швидшим за допомогою різних операторів sql (select-update-delete-insert).

Тож моє запитання: Чому хтось використовує Laravel Eloquent проти звичайного конструктора запитів?

Eloquent - це реалізація Laravel шаблону Active Record, який має всі свої сильні та слабкі сторони.

Активний запис є хорошим рішенням для обробки однієї сутності в CRUD-манері - тобто створити нову сутність із заповненими властивостями, а потім зберегти її в базі даних, завантажити запис із бази даних або видалити.

Ви отримаєте багато користі від таких красномовних функцій, як брудна перевірка (надсилати SQL UPDATE лише для полів, які були змінені), події моделі (наприклад, надсилати адміністративні сповіщення або оновлювати лічильники статистики, коли хтось створив новий обліковий запис), риси ( позначки часу, м'які видалення, ваші власні риси) нетерпляче / ледаче завантаження тощо. Ви також можете застосувати керований доменом шаблон та реалізувати деякі елементи бізнес-логіки у своїх об'єктах Active Record, наприклад, перевірку, управління відносинами, розрахунки тощо.

Але, як ви вже знаєте, Active Record має певну ціну продуктивності.

Коли ви обробляєте один запис або кілька записів, ні про що турбуватися. Але для випадків, коли ви читаєте багато записів (наприклад, для сіток даних, для звітів, для пакетної обробки тощо), простіші DBметоди Laravel є кращим підходом.

Для наших додатків на базі Laravel ми використовуємо обидва підходи, як ми вважаємо доречними. Ми використовуємо форми Eraquent для інтерфейсу користувача Laravel для обробки одного запису та використовуємо DBметоди (підкріплені поданнями SQL з додатковими налаштуваннями продуктивності, специфічні для механізму бази даних) для отримання даних для таблиць інтерфейсу, завдань експорту тощо. Це також добре працює з RESTful API - Eloquent for GET , ВСТАНОВИТИ, РОЗМІСТИТИ, ВИДАЛИТИ за допомогою ключа та DBдля ОТРИМАТИ без ключа, але з фільтрами та сортуванням та підкачуванням.

Так, в якомусь випадку ти маєш рацію. Коли ми маємо більше даних і майже на кожному веб-сайті, дані насправді не малі. Тоді краще використовувати DB Query, ніж Eloquent Query .

У випуску продуктивності Eloquent VS DB я чув,

Щоб вставити 1000 рядків для простої таблиці, Eloquent займає 1,2 секунди, і в цьому випадку фасади БД займають лише 800 мілі секунд (мс).

То чому тоді красномовний? Це нічого не потрібно?

Відповідь така - красномовний також необхідний. Причина-

Щоб створити кращі стосунки та отримати результати з огляду на стільки простого синтаксису, коли потрібно приєднатися.

Красномовний також для тих, хто не має великих знань про запити SQL .

Структура MVC відповідає правилам читабельності коду, ремонтопридатності коду та того, що таке красномовний, ви це знаєте. Порівняння коду нижче. Очевидно, Красномовство краще читати.

// 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.

Отже, нарешті це зрозуміло - коли ми будемо використовувати Запит до бази даних і Коли ми будемо використовувати Красномовний запит.

Редагувати - Приклад із реального життя

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. Я повинен вибрати там звичайні фасади БД. Це швидший пошук записів із такої кількості записів.

Ви можете перевірити ефективність запитів за допомогою налагоджувача Laravel (популярний пакет для перевірки продуктивності записів Eloquent / Database / часу виконання)

Тепер це ваш вибір. Що ви хочете зробити ...

Ви можете перевірити тут повний код, порівнявши код із продуктивністю, споживанням пам'яті та якістю коду про них - https://devsenv.com/tutorials/laravel-eloquent-vs-db-query-builder-performance-and-other-statistics

Чому Laravel Eloquent:

1. Виконання запиту OOPспособом.
2. Простий у використанні, ніж необроблений запит або query builder.
3. Немає прив'язки з table schema. тобто навіть якщо ви змінили назву таблиці, не потрібно торкатися жодної query(може бути 1000 query), щоб вона працювала. Просто змініть назву таблиці красномовно model.
4. Відносини між столами можна підтримувати елегантно. Просто згадайте тип відносин, більше нічого ( JOIN, LEFT JOIN, RIGHT JOINтощо), необхідного у запиті, для отримання даних відповідних таблиць.
5. Запити легко читаються під час написання за допомогою Eloquent порівняно з Query Builder.
6. Ви можете використовувати методи, сфери застосування, аксесуари, модифікатор тощо всередині Моделі, яка проста в обслуговуванні.

Коли мова заходить про продуктивність і додаток росте, для порівняння візьміть бабло за наступними таблицями:

Порівняння середнього часу відгуку вибраної операції між 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 таким легким та зручним для новачків.

Красномовний ORM найкраще підходить для роботи з меншою кількістю даних у певній таблиці. З іншого боку, конструктор запитів займає менше часу, щоб обробляти численні дані в одній або декількох таблицях швидше, ніж Eloquent ORM.

У моєму випадку я використовую ELoquent ORM у програмі з таблицями, які містять менше 17500 записів. Щоразу, коли я передбачаю, що таблиця буде містити більше 17500 записів, найкращим є конструктор запитів.

Крім того, в додатках з підзапитами я віддаю перевагу конструктору запитів над ELoquent ORM.

Між ними є багато різного

1. Запит Builder набагато швидший, ніж ORM, ви тестуєте його за допомогою налагоджувача. ось як можна протестувати https://scotch.io/tutorials/debugging-queries-in-laravel .
2. Запит Builder вимагає менше часу на виконання, коли ви працюєте з великими обсягами даних, наприклад, якщо у вашій базі даних більше 1000000, ніж ORM.
3. Запит Builder найкраще підходить для великого обсягу даних. Orm найкраще підходить, коли ви працюєте з відношеннями, оскільки він надає багато методів відношення для визначення відношення між таблицями.
4. Запит будівельника використовує об'єднання sql, але використання orm для роботи з 2 таблицями або більше.

Мені подобається використовувати конструктор запитів під час створення складного запиту з бази даних, оскільки він здається простим у використанні. Для роботи з єдиним столом я люблю красномовного.