LaravelEloquent 与 DB facade: 为什么使用 Eloquent 并降低性能？

It is just my opinion, not a comprehensive answer. I use whatever is more convenient in a given situation.

If I come across a package or code written either in eloquent or query builder, I use whatever is being used.

I found query builder to be more intuitive if I create something from scratch so I use it more often.

When it comes to Laravel, it seems, the ease and speed of developing an app is more important then performance. I really like that they make everything very easy even for someone with little prior knowledge of php/mysql. In some cases eloquent is easier than query builder. In others vice versa. I think having many ways of doing something is what makes Laravel so easy and newbie friendly.

Why use Laravel Eloquent instead of the DB facade:

1. You can write code that is object-oriented.

2. It is easier to use than writing raw SQL or using the DB facade.

3. There is no binding to the table schema, so for example if you want to change your table name, you don't have to touch a single Eloquent query, just change the table name in the Eloquent model.

4. Relationships between tables can be maintained in an elegant way. Just mention the type of relationship (JOIN, LEFT JOIN, RIGHT JOIN etc.) to get data from related tables.

5. Eloquent queries are more readable than raw SQL or the DB facade.

6. You can use methods, scopes, accessors, modifiers etc. inside of a model, which is a maintainable pattern.

Eloquent is Laravel's implementation of Active Record pattern and it comes with all its strengths and weaknesses.

Active Record is a good solution for processing a single entity in CRUD manner - that is, create a new entity with filled properties and then save it to a database, load a record from a database, or delete.

You will benefit a lot from Eloquent's features such as dirty checking (to send SQL UPDATE only for the fields which have been changed), model events (e.g. to send administrative alerts or update statistics counters when someone has created a new account), traits (timestamps, soft deletes, your custom traits) eager/lazy loading etc. You can also apply domain-driven pattern and implement some pieces of business logic in your Active Record entities, for example, validation, managing relations, calculations etc.

But, as you already know, Active Record comes with some performance price.

When you process a single record or a few records, there is nothing to worry about. But for cases when you read lots of records (e.g. for datagrids, for reports, for batch processing etc.) the plain Laravel DB methods is a better approach.

For our Laravel based applications we are using both approaches as we see appropriate. We use Laravel's Eloquent for UI forms to process a single record and use DB methods (backed by SQL views with additional database engine specific performance tweaks) to retrieve data for UI tables, export tasks etc. It also works well with RESTful APIs - Eloquent for GET, PUT, POST, DELETE with a key and DB for GET without key but with filters and sorting and paging.

I like using query builder when building complex query from database because it seems easy to use. For working with a single table, I like eloquent.

Yes, in some case you are correct.

When you are handling more data, it is better to use Laravel's DB facade query builder than Laravel's Eloquent ORM.

From performance tests, inserting 1000 rows in a simple table takes Eloquent 1.2 seconds whereas the DB facade takes only 800 milliseconds.

So why use Eloquent at all? Eloquent is also important, because:

• It has a simpler syntax than the DB facade.

• It is easier for developers who don't know SQL. You need to know SQL to use the DB facade.

• Code written using Eloquent is more readable and thus more maintainable than code written using the DB facade:

  // With Eloquent
  $student = App\Student::find($id);
  
  
  // With the DB facade
  $student = DB::table('student')->where('id', $id)->first();
  

• If you want to change the database, it will be easier with Laravel Eloquent as it can handle many different databases, whereas the DB facade requires you to write SQL which may have to be rewritten for a different database.

So use Eloquent when you work on a small site with simple CRUD operations, and use the DB facade when you use many joins and other features not supported by Eloquent.

Real-life examples:

1. You're making a university website, which contains 5,000 teachers, and 10,000 students, and some notices and files. It would be better to build this site with Laravel Eloquent as it is simple and readable.

2. You're making a high-traffic site like Stack Overflow, which serves more than 100 million people every month and has more than 70 million posts. It would be better to use the DB facade as it is faster and will lead to significantly faster response times.

You can check your query performance using Laravel Debugbar.

Here is a full comparison of performance, memory consumption and code quality between Eloquent and the DB facade.

When it comes to performance and the application grows, for the sake of comparison, take a look at the following tables:

Eloquent ORM average response times:

Raw SQL average response times:

Article Reference

Eloquent ORM is best suited working with fewer data in a particular table. On the other side, query builder takes less time to handle numerous data whether in one or more tables faster than Eloquent ORM.

In my case, I use ELoquent ORM in an application with tables that will hold less than 17500 entries. Whenever I anticipate the table will hold more than 17500 entries, query builder is the best.

Further, in applications with subqueries, I prefer query builder over ELoquent ORM.

There is many different between them

1. Builder query is much faster than ORM you test it by debugger. here is the how you can test https://scotch.io/tutorials/debugging-queries-in-laravel.
2. Builder query less time to execute when you work with large amount data like if have more 1,00,000 in your database than ORM.
3. Builder query is best suitable for large amount of data.Orm is best suitable when you work with relation because its provide many relation method to define relation between tables.
4. Builder query use join of sql but orm use relation to work 2 tables or more table.