Laravel Eloquent vs query builder - Pourquoi utiliser eloquent pour diminuer les performances

Question

J'ai fait quelques tests de performance entre Laravel query builder et eloquent. Query builder était beaucoup plus rapide avec diverses instructions sql (select-update-delete-insert).

Ma question est donc la suivante : pourquoi quelqu'un utilise-t-il Laravel Eloquent plutôt qu'un simple constructeur de requêtes ?

Answer 1

Eloquent est l'implémentation de Laravel du modèle Active Record et il est livré avec toutes ses forces et ses faiblesses.

Active Record est une bonne solution pour traiter une seule entité à la manière CRUD - c'est-à-dire créer une nouvelle entité avec des propriétés remplies, puis l'enregistrer dans une base de données, charger un enregistrement depuis une base de données ou le supprimer.

Vous bénéficierez beaucoup des fonctionnalités d'Eloquent telles que le dirty checking (pour envoyer des UPDATE SQL uniquement pour les champs qui ont été modifiés), les événements de modèle (par exemple, pour envoyer des alertes administratives ou mettre à jour les compteurs de statistiques lorsque quelqu'un a créé un nouveau compte), les traits (timestamps, soft deletes, vos traits personnalisés), le chargement rapide/lent, etc. Vous pouvez également appliquer le modèle piloté par le domaine et implémenter certains éléments de la logique métier dans vos entités Active Record, par exemple, la validation, la gestion des relations, les calculs, etc.

Mais, comme vous le savez déjà, Active Record a un prix en termes de performances.

Lorsque vous traitez un seul enregistrement ou quelques enregistrements, il n'y a pas lieu de s'inquiéter. Mais pour les cas où vous lisez beaucoup d'enregistrements (par exemple pour les grilles de données, les rapports, les traitements par lots, etc. DB est une meilleure approche.

Pour nos applications basées sur Laravel, nous utilisons les deux approches comme nous le jugeons approprié. Nous utilisons Eloquent de Laravel pour les formulaires de l'interface utilisateur afin de traiter un seul enregistrement et nous utilisons DB (soutenues par des vues SQL avec des ajustements supplémentaires de performance spécifiques au moteur de base de données) pour récupérer des données pour les tableaux de l'interface utilisateur, les tâches d'exportation, etc. Il fonctionne également très bien avec les API RESTful - Eloquent pour GET, PUT, POST, DELETE avec une clé et DB pour un GET sans clé mais avec des filtres, un tri et une pagination.

Answer 2

Oui, dans certains cas, vous avez raison. Quand nous aurons plus de données et presque dans chaque site, les données ne sont pas petits vraiment. Alors il est préférable d'utiliser DB Query plutôt qu'Eloquent Query. .

Dans un problème de performance d'Eloquent VS DB J'ai entendu ça,

Pour insérer 1000 lignes d'une table simple, Eloquent prend 1,2 secondes. dans ce cas, les façades DB ne prennent que 800 mili secondes(ms).

Alors pourquoi être éloquent ? Cela n'est-il pas nécessaire ?

La réponse est - L'éloquence est également nécessaire. Cause :

A créer une meilleure relation et obtenir les résultats en vue avec une syntaxe si simple, lorsqu'il faut joindre.

Eloquent est aussi pour ceux qui n'ont pas une grande connaissance des requêtes SQL. .

Un cadre MVC suivre les règles de lisibilité et de maintenabilité du code. et ce qu'est Eloquent, vous le savez. Une comparaison de codes ci-dessous. Évidemment, Eloquent est plus facile à lire.

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

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

La partie la plus importante est si nous voulez changer d'autre base de données Dans ce cas, Laravel Eloquent résoudra tous les problèmes d'une seule main. Il peut gérer différents types de bases de données.

Ainsi, lorsque nous utilisons les façades d'Eloquent et When DB :

1. Lorsque nous travaillons sur un site simple et de petite taille avec des CRUD simples et que les enregistrements ne sont pas factuels, nous utilisons Eloquent. ne sont pas des faits, alors on utilise Eloquent.
2. Lorsque nous travaillons sur un grand nombre d'enregistrements, il est préférable d'utiliser DB Query plutôt qu'Eloquent.

Donc, finalement, il est clair que - quand nous utiliserons Database Query et quand nous utiliserons Eloquent Query.

Editer - Exemple concret

1. Je fais un Site de l'université . Qui peut contenir au maximum 5,000 teachers and 10,000 students and some notices and files . Il est alors préférable de le faire avec le simple Laravel Eloquent qui est très standard et lisible.
2. Maintenant, je fais un site comme Stackoverflow . Qui peut contenir plus de 1,000,0000 (1 crore) posts and many more things . Je dois choisir les façades conventionnelles de la DB. C'est plus rapide pour rechercher les messages à partir de tant d'enregistrements.

Vous pouvez vérifier les performances de vos requêtes en utilisant Barre de débogage Laravel (Un paquet populaire pour vérifier les performances/temps d'exécution des requêtes Eloquent/Database)

Maintenant, c'est à vous de choisir. Ce que vous voulez faire...

Vous pouvez consulter ici une comparaison complète, code par code, des performances, de la consommation de mémoire et de la qualité du code de ces produits. https://devsenv.com/tutorials/laravel-eloquent-vs-db-query-builder-performance-and-other-statistics

Answer 3

Pourquoi Laravel Eloquent :

1. Exécution de la requête dans un OOP manière.
2. Plus facile à utiliser que les requêtes brutes ou query builder .
3. Pas de liaison avec table schema . c.-à-d. que même si vous changez le nom de votre table, il n'est pas nécessaire de toucher à une simple query (il peut y avoir 1000 query ) pour que cela fonctionne. Changez simplement le nom de la table dans eloquent model .
4. Les relations entre les tables peuvent être maintenues de manière élégante. Il suffit de mentionner le type de relation, rien d'autre( JOIN, LEFT JOIN, RIGHT JOIN etc.) nécessaires dans la requête pour obtenir les données des tables liées.
5. Les requêtes sont très lisibles lorsqu'elles sont écrites à l'aide d'Eloquent par rapport à Query Builder.
6. Vous pouvez utiliser des méthodes, des champs d'application, des accesseurs, des modificateurs, etc. à l'intérieur d'un modèle, ce qui est facile à maintenir.

Answer 4

En ce qui concerne les performances et la croissance de l'application, à titre de comparaison, jetez un coup d'œil aux tableaux suivants :

Comparaison du temps de réponse moyen des opérations de sélection entre Eloquent ORM et Raw SQL

Temps de réponse moyen d'Eloquent ORM

Joins | Average (ms) 
------+-------------
1     | 162.2 
3     | 1002.7 
4     | 1540.0 

Result of select operation average response time for Eloquent ORM 

---

Temps de réponse moyen de SQL brut

Joins | Average (ms) 
------+-------------
1     | 116.4 
3     | 130.6 
4     | 155.2 

Result of select operation average response time for Raw SQL 

Référence de l'article

Answer 5

C'est juste mon opinion, pas une réponse complète. J'utilise ce qui est le plus pratique dans une situation donnée.

Si je tombe sur un paquet ou un code écrit soit dans eloquent soit dans query builder, j'utilise ce qui est utilisé.

Je trouve que le générateur de requêtes est plus intuitif lorsque je crée quelque chose à partir de rien, donc je l'utilise plus souvent.

Quand il s'agit de Laravel, il semble que la facilité et la rapidité de développement d'une application soient plus importantes que les performances. J'aime beaucoup le fait qu'ils rendent tout très facile, même pour quelqu'un ayant peu de connaissances préalables en php/mysql. Dans certains cas, eloquent est plus facile que query builder. Dans d'autres, c'est l'inverse. Je pense que le fait d'avoir plusieurs façons de faire quelque chose est ce qui rend Laravel si facile et convivial pour les débutants.