web-dev-qa-db-fra.com

Laravel Eloquent vs query builder - Pourquoi utiliser eloquent pour réduire les performances

J'ai fait un test de performance entre le constructeur de requêtes Laravel et éloquent. Le constructeur de requêtes é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 contre un simple constructeur de requêtes?

mysqlsqlperformancelaravellaravel-5
42
Panagiotis Koursaris

Eloquent est la mise en œuvre par Laravel du modèle Active Record. Il comporte toutes ses forces et ses faiblesses. C'est une bonne solution à utiliser lorsque vous traitez une seule entité de manière CRUD, c'est-à-dire que vous lisez dans la base de données ou créez une nouvelle entité, puis enregistrez-la ou supprimez-la. Les fonctionnalités d’Eloquent, telles que le contrôle malpropre (pour envoyer des mises à jour SQL uniquement pour les champs modifiés), des événements de modèle (par exemple, pour envoyer une alerte administrative ou mettre à jour un compteur de statistiques quand un utilisateur a créé un nouveau compte), des traits timestamps, suppressions douces, traits personnalisés) chargement avide/paresseux, etc.

Mais, comme vous le savez déjà, cela a un prix de performance. Lorsque vous traitez un ou plusieurs enregistrements, vous n'avez rien à craindre. Mais dans les cas où vous lisez beaucoup d'enregistrements (par exemple, pour des datagrids, des rapports, pour un traitement par lots, etc.), la base de données simple constitue une meilleure approche.

C'est exactement ce que nous faisons pour notre application: utiliser Eloquent de Laravel dans des formulaires Web pour traiter un seul enregistrement et utiliser une base de données (avec des vues SQL) pour extraire des données pour des grilles, les exporter, etc.

74
JustAMartin

Pourquoi Laravel Eloquent:

  1. Exécution d'une requête d'une manière OOP.
  2. Facile à utiliser qu'une requête brute ou query builder.
  3. Aucune liaison avec table schema. Même si vous modifiez le nom de votre table, vous n'avez pas besoin de toucher une seule variable query (il peut y en avoir 1 000 query) pour la faire fonctionner. Il suffit de changer le nom de la table dans model. 
  4. Les relations entre les tables peuvent être maintenues de manière élégante. Il suffit de mentionner le type de relation, plus rien (JOIN, LEFT JOIN, RIGHT JOIN etc.) n’est nécessaire dans la requête pour obtenir les données des tables associées.
  5. Les requêtes sont très lisibles lorsqu'elles sont écrites en comparant Eloquent à Query Builder.
23
Imran

Quand il s’agit de performances et que l’application prend de l’ampleur, à des fins de comparaison, prenez un butin aux tableaux suivants:

Comparaison du temps de réponse moyen d'une opération de sélection entre Eloquent ORM et Raw SQL

Temps de réponse moyen d'ORM éloquent

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 en 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

7
Mohammad Naji

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

Si je tombe sur un paquet ou un code écrit en éloquent ou en constructeur de requêtes, j'utilise tout ce qui est utilisé.

J'ai trouvé que le constructeur de requêtes était plus intuitif si je créais quelque chose à partir de rien, donc je l'utilisais plus souvent.

En ce qui concerne Laravel, il semble que la facilité et la rapidité de développement d’une application soient plus importantes que la performance. J'aime vraiment qu'ils rendent tout très facile même pour quelqu'un avec peu de connaissances préalables de php/mysql. Dans certains cas, éloquent est plus facile que le constructeur de requêtes. Dans d'autres, vice versa. Je pense que Laravel est si facile et convivial pour les débutants qu’il existe de nombreuses façons de procéder.

4
Arthur Tarasov

J'aime utiliser le générateur de requêtes lors de la création d'une requête complexe à partir d'une base de données car elle semble facile à utiliser. Pour travailler avec une seule table, j'aime bien éloquent.

1
HENG Vongkol

Eloquent ORM est le mieux adapté pour travailler avec moins de données dans un tableau particulier. D'autre part, le générateur de requêtes prend moins de temps pour traiter de nombreuses données, que ce soit dans une ou plusieurs tables, plus rapidement que Eloquent ORM.

Dans mon cas, j'utilise ELoquent ORM dans une application avec des tables contenant moins de 17500 entrées. Chaque fois que je prévois que la table contiendra plus de 17500 entrées, le constructeur de requêtes est le meilleur.

De plus, dans les applications avec sous-requêtes, je préfère le constructeur de requêtes à ELoquent ORM.

0
Patrick N.