it-swarm.com.de

Laravel Eloquent vs. Query Builder - Warum Eloquent verwenden, um die Leistung zu verringern

Ich habe einige Leistungstests zwischen Laravel Query Builder und Eloquent durchgeführt. Der Abfrage-Generator war mit verschiedenen SQL-Anweisungen (select-update-delete-insert) viel schneller.

Meine Frage ist also: Warum verwendet Laravel Eloquent gegen einfachen Abfrage-Generator?

42

Eloquent ist die Implementierung des Active Record-Patterns von Laravel und bringt all seine Stärken und Schwächen mit sich. Dies ist eine gute Lösung, wenn Sie eine einzelne Entität auf eine CRUD-Weise verarbeiten, dh aus einer Datenbank lesen oder eine neue Entität erstellen und diese dann speichern oder löschen. Sie profitieren von den Funktionen von Eloquent, z. B. durch Dirty-Checking (zum Senden von SQL-UPDATE nur für geänderte Felder), Modellereignisse (z. B. zum Senden von Verwaltungsbenachrichtigungen oder zum Aktualisieren des Statistikzählers, wenn ein neuer Account erstellt wurde), Zeitstempel, weiche Löschvorgänge, benutzerdefinierte Merkmale).

Aber, wie Sie bereits wissen, ist dies mit einem gewissen Preis verbunden. Wenn Sie einzelne oder wenige Datensätze bearbeiten, müssen Sie sich keine Sorgen machen. In Fällen, in denen Sie viele Datensätze lesen (z. B. für Datagrids, für Berichte, für die Stapelverarbeitung usw.), ist die einfache Datenbank die bessere Lösung.

Für unsere Anwendung tun wir genau das: Verwenden von Laravel Eloquent in Webformularen zur Verarbeitung eines einzelnen Datensatzes und DB (mit SQL-Ansichten) zum Abrufen von Daten für Grids, Export usw.

74
JustAMartin

Ja, manchmal hast du recht. Wenn wir mehr Daten haben und fast an jedem Standort sind die Daten nicht wirklich klein. Dann es ist besser, DB Query zu verwenden als die Eloquent Query.

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

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

Warum also dann eloquent? Ist das nicht nötig?

Antwort ist - Eloquent ist auch notwendig. Ursache-

Um schaffen Sie eine bessere Beziehung und erhalten Sie die Ergebnisse mit so viel einfacher Syntax, wenn es beitreten muss.

Eloquent ist auch für diejenigen, die sich mit SQL-Abfragen nicht auskennen.

Ein MVC-Framework Befolgen Sie die Regeln für Code Readability, Code Maintainability und welches Eloquent es ist, das wissen Sie. Ein Code-Vergleich unten. Natürlich ist Eloquent besser zu lesen.

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

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

Wichtigster Teil ist Wenn wir andere Datenbank ändern möchten}, wird die reine Abfrage sehr viel Kopfschmerzen bereiten, und in diesem Fall löst Laravel Eloquent alle Probleme mit einer Hand. Es können verschiedene Arten von Datenbanken behandelt werden.

Wenn wir also Eloquent und When DB Fassaden verwenden:

  1. Wenn wir mit einfachen CRUDs an einer einfachen und kleinen Datensatzseite arbeiten und dort Datensätze Nicht vorhanden sind, verwenden Sie Eloquent dort. 
  2. Wenn wir an vielen Datensätzen arbeiten, ist es besser, DB Query zu verwenden als Eloquent.

Endlich ist klar, dass - wann wir die Datenbankabfrage verwenden und wann wir die Eloquent-Abfrage verwenden.

Bearbeiten - Real Life-Beispiel

  1. Ich mache eine University Website. Die dürfen maximal 5,000 teachers and 10,000 students and some notices and files enthalten. Dann ist es besser, dies mit einfachem Laravel Eloquent zu tun, das sehr gut lesbar ist.
  2. Jetzt mache ich eine Site wie Stackoverflow. Welches kann mehr als 1,000,0000 (1 crore) posts and many more things enthalten. Ich werde dort die konventionellen DB-Fassaden wählen müssen. Es ist schneller für das Durchsuchen der Beiträge aus so vielen Datensätzen.

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

24

Warum Laravel Eloquent:

  1. Abfrage auf OOP-Art ausführen.
  2. Einfach zu verwenden als reine Abfrage oder query builder.
  3. Keine Bindung mit table schema. Das heißt, auch wenn Sie Ihren Tabellennamen ändern, müssen Sie nicht ein einzelnes query (es kann 1000 query haben) berühren, damit es funktioniert. Ändern Sie einfach den Tabellennamen in model
  4. Die Beziehung zwischen Tischen kann auf elegante Weise aufrechterhalten werden. Nennen Sie einfach die Art der Beziehung, nichts anderes (JOIN, LEFT JOIN, RIGHT JOIN usw.), das in der Abfrage mehr benötigt wird, um Daten von verwandten Tabellen zu erhalten.
  5. Abfragen, die während des Schreibens mit Eloquent sehr gut lesbar sind und mit dem Query Builder verglichen werden.
23
Imran

Wenn es um Leistung geht und die Anwendung wächst, nehmen Sie zum Vergleich eine Beute an den folgenden Tabellen:

Vergleich der durchschnittlichen Antwortzeit für Auswahloperationen zwischen Eloquent ORM und Raw SQL

Eloquent 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 durchschnittliche Antwortzeit von SQL

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

Result of select operation average response time for Raw SQL 

Artikelreferenz

7
Mohammad Naji

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

Wenn ich auf ein Paket oder einen Code stoße, der entweder in eloquent oder im Query Builder geschrieben wurde, verwende ich das, was verwendet wird.

Ich fand den Query Builder intuitiver, wenn ich etwas von Grund auf neu erstelle, also häufiger.

In Bezug auf Laravel scheint die Entwicklung und Entwicklung einer App wichtiger zu sein als die Leistung. Ich mag es wirklich, dass sie alles sehr einfach machen, selbst für jemanden mit geringen Vorkenntnissen in PHP/MySQL. In manchen Fällen ist Eloquent einfacher als der Query Builder. In anderen umgekehrt. Ich denke, dass es viele Wege gibt, etwas zu tun, was Laravel so einfach und neulingefreundlich macht.

4
Arthur Tarasov

Beim Erstellen komplexer Abfragen aus der Datenbank mag ich den Abfrage-Generator, da er einfach zu verwenden scheint. Für die Arbeit mit einem einzigen Tisch mag ich es, eloquent zu sein.

1
HENG Vongkol

Eloquent ORM eignet sich am besten für das Arbeiten mit weniger Daten in einer bestimmten Tabelle. Andererseits benötigt der Query Builder weniger Zeit für die Verarbeitung zahlreicher Daten, unabhängig davon, ob er in einer oder mehreren Tabellen schneller ist als Eloquent ORM.

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

Des Weiteren bevorzuge ich bei Anwendungen mit Unterabfragen den Abfrageersteller dem ELoquent ORM.

0
Patrick N.