Laravel Eloquent vs Query Builder - Warum eloquent verwenden, um die Leistung zu verringern [geschlossen]

Ich habe einen Leistungstest zwischen Laravel Query Builder und Beredsamkeit durchgeführt. Der Abfrage-Generator war mit verschiedenen SQL-Anweisungen (Select-Update-Delete-Insert) viel schneller.

Meine Frage lautet also: Warum verwendet jemand Laravel Eloquent gegen den einfachen Abfrage-Builder?

Eloquent ist Laravels Implementierung des Active Record-Musters und weist alle seine Stärken und Schwächen auf.

Active Record ist eine gute Lösung für die Verarbeitung einer einzelnen Entität auf CRUD-Weise. Erstellen Sie also eine neue Entität mit gefüllten Eigenschaften und speichern Sie sie in einer Datenbank, laden Sie einen Datensatz aus einer Datenbank oder löschen Sie sie.

Sie profitieren stark von Eloquents Funktionen wie Dirty Checking (um SQL UPDATE nur für die geänderten Felder zu senden), Modellereignissen (z. B. um administrative Warnungen zu senden oder Statistikzähler zu aktualisieren, wenn jemand ein neues Konto erstellt hat), Eigenschaften ( Zeitstempel, weiche Löschvorgänge, Ihre benutzerdefinierten Merkmale) eifriges / verzögertes Laden usw. Sie können auch domänengesteuerte Muster anwenden und einige Teile der Geschäftslogik in Ihre Active Record-Entitäten implementieren, z. B. Validierung, Verwaltung von Beziehungen, Berechnungen usw.

Wie Sie bereits wissen, ist Active Record mit einem gewissen Leistungspreis verbunden.

Wenn Sie einen einzelnen Datensatz oder einige Datensätze verarbeiten, müssen Sie sich keine Sorgen machen. In Fällen, in denen Sie viele Datensätze lesen (z. B. für Datagrids, Berichte, Stapelverarbeitung usw.), sind die einfachen Laravel- DBMethoden ein besserer Ansatz.

Für unsere Laravel-basierten Anwendungen verwenden wir beide Ansätze, wie wir es für angemessen halten. Wir verwenden Laravels Eloquent for UI-Formulare, um einen einzelnen Datensatz zu verarbeiten, und verwenden DBMethoden (unterstützt durch SQL-Ansichten mit zusätzlichen datenbankmodulspezifischen Leistungsverbesserungen), um Daten für UI-Tabellen abzurufen, Aufgaben zu exportieren usw. Es funktioniert auch gut mit RESTful-APIs - Eloquent for GET , PUT, POST, DELETE mit einem Schlüssel und DBfür GET ohne Schlüssel, aber mit Filtern und Sortieren und Paging.

Ja, in einigen Fällen haben Sie recht. Wenn wir mehr Daten haben und fast auf jeder Site, sind die Daten nicht wirklich klein. Dann ist es besser, DB Query als Eloquent Query zu verwenden .

In einem Leistungsproblem von Eloquent VS DB habe ich das gehört,

Das Einfügen von 1000 Zeilen für eine einfache Tabelle Eloquent dauert 1,2 Sekunden, und in diesem Fall benötigen DB-Fassaden nur 800 Millisekunden (ms).

Warum dann Eloquent? Ist das nicht nötig?

Antwort ist - Beredsam ist auch notwendig. Ursache-

Um eine bessere Beziehung zu erstellen und die Ergebnisse mit so viel einfacher Syntax anzuzeigen, wenn eine Verbindung erforderlich ist.

Eloquent ist auch für diejenigen gedacht , die nicht viel über SQL-Abfragen wissen .

Ein MVC-Framework folgt den Regeln für Code-Lesbarkeit, Code-Wartbarkeit und was Eloquent ist, das wissen Sie. Ein Codevergleich unten. Offensichtlich ist Eloquent besser zu lesen.

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

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

Der wichtigste Teil ist, wenn wir eine andere Datenbank ändern möchten, wird uns die rohe Abfrage viel Kopfzerbrechen bereiten, und in diesem Fall wird Laravel Eloquent alle Probleme mit einer Hand lösen. Es kann verschiedene Arten von Datenbanken verarbeiten.

Wenn wir also Eloquent- und When DB-Fassaden verwenden:

1. Wenn wir an einer einfachen und kleinen Datensatz-Site mit einfachem CRUD arbeiten und dort keine Fakten vorliegen, verwenden Sie dort Eloquent.
2. Wenn wir an vielen Datensätzen arbeiten, ist es besser, DB Query als Eloquent zu verwenden.

Schließlich ist klar, dass - wann wir die Datenbankabfrage verwenden und wann wir die eloquente Abfrage verwenden.

Bearbeiten - Beispiel aus dem wirklichen Leben

1. Ich mache eine Universitätswebsite . Welches kann maximal enthalten 5,000 teachers and 10,000 students and some notices and files. Dann ist es besser, dies mit einfachem Laravel Eloquent zu tun, das sehr normal und lesbar ist.
2. Jetzt mache ich eine Seite wie Stackoverflow . Welches kann mehr als enthalten 1,000,0000 (1 crore) posts and many more things. Ich muss dort die konventionellen DB-Fassaden wählen. Es ist schneller, die Beiträge aus so vielen Datensätzen zu durchsuchen.

Sie können Ihre Abfrageleistung mithilfe der Laravel-Debugbar überprüfen (ein beliebtes Paket zum Überprüfen der Leistung / Ausführungszeiten von Eloquent- / Datenbankabfragen).

Jetzt haben Sie die Wahl. Was du machen willst ...

Sie können hier einen vollständigen Code durch Codevergleich mit Leistung, Speicherverbrauch und Codequalität überprüfen - https://devsenv.com/tutorials/laravel-eloquent-vs-db-query-builder-performance-and-other-statistics

Warum Laravel Eloquent:

1. Abfrage auf eine OOPArt und Weise ausführen .
2. Einfach zu bedienen als Rohabfrage oder query builder.
3. Keine Bindung mit table schema. Das heißt, selbst wenn Sie Ihren Tabellennamen ändern, müssen Sie keinen einzigen berühren query(möglicherweise 1000 query), damit er funktioniert. Ändern Sie einfach den Tabellennamen in eloquent model.
4. Die Beziehung zwischen Tabellen kann auf elegante Weise aufrechterhalten werden. Erwähnen Sie einfach die Art der Beziehung, nichts anderes ( JOIN, LEFT JOIN, RIGHT JOINusw.), das in der Abfrage mehr benötigt wird, um Daten verwandter Tabellen zu erhalten.
5. Abfragen sind beim Schreiben mit Eloquent im Vergleich zu Query Builder gut lesbar.

Wenn es um Leistung geht und die Anwendung wächst, sollten Sie zu Vergleichszwecken die folgenden Tabellen verwenden:

Vergleich der durchschnittlichen Antwortzeit für ausgewählte Operationen zwischen Eloquent ORM und Raw SQL

Eloquente ORM durchschnittliche Antwortzeit

Joins | Average (ms) 
------+-------------
1     | 162,2 
3     | 1002,7 
4     | 1540,0 

Result of select operation average response time for Eloquent ORM 

Durchschnittliche Antwortzeit für Raw SQL

Joins | Average (ms) 
------+-------------
1     | 116,4 
3     | 130,6 
4     | 155,2 

Result of select operation average response time for Raw SQL 

Artikelreferenz

Es ist nur meine Meinung, keine umfassende Antwort. Ich benutze alles, was in einer bestimmten Situation bequemer ist.

Wenn ich auf ein Paket oder einen Code stoße, der entweder in eloquent oder im Abfrage-Generator geschrieben ist, verwende ich alles, was verwendet wird.

Ich fand den Abfrage-Generator intuitiver, wenn ich etwas von Grund auf neu erstelle, damit ich es häufiger verwende.

Wenn es um Laravel geht, ist die Leichtigkeit und Geschwindigkeit der Entwicklung einer App anscheinend wichtiger als die Leistung. Ich mag es wirklich, dass sie alles sehr einfach machen, selbst für jemanden mit geringen Vorkenntnissen in PHP / MySQL. In einigen Fällen ist eloquent einfacher als der Abfrage-Generator. In anderen umgekehrt. Ich denke, viele Möglichkeiten zu haben, etwas zu tun, macht Laravel so einfach und neulingfreundlich.

Eloquent ORM eignet sich am besten für die Arbeit mit weniger Daten in einer bestimmten Tabelle. Auf der anderen Seite benötigt der Abfrage-Generator weniger Zeit, um zahlreiche Daten in einer oder mehreren Tabellen schneller zu verarbeiten als Eloquent ORM.

In meinem Fall verwende ich ELoquent ORM in einer Anwendung mit Tabellen, die weniger als 17500 Einträge enthalten. Wann immer ich davon ausgehe, dass die Tabelle mehr als 17500 Einträge enthalten wird, ist der Abfrage-Generator der beste.

Außerdem bevorzuge ich in Anwendungen mit Unterabfragen den Abfrage-Generator gegenüber ELoquent ORM.

Es gibt viele verschiedene zwischen ihnen

1. Die Builder-Abfrage ist viel schneller als ORM, das Sie per Debugger testen. Hier erfahren Sie, wie Sie https://scotch.io/tutorials/debugging-queries-in-laravel testen können .
2. Builder fragt weniger Zeit für die Ausführung ab, wenn Sie mit großen Datenmengen arbeiten, z. B. wenn Ihre Datenbank mehr als 1.00.000 als ORM enthält.
3. Die Builder-Abfrage eignet sich am besten für große Datenmengen. Orm eignet sich am besten für die Arbeit mit Relationen, da es viele Beziehungsmethoden zum Definieren der Beziehung zwischen Tabellen bietet.
4. Builder-Abfrage verwendet Join von SQL, aber Orm verwendet Relation, um 2 Tabellen oder mehr Tabellen zu bearbeiten.

Ich verwende gerne den Abfrage-Generator, wenn ich komplexe Abfragen aus einer Datenbank erstelle, weil sie einfach zu verwenden scheinen. Für die Arbeit mit einem einzigen Tisch mag ich beredt.