netconnect's avatar

Eloquent or DB:Manager?

Hi guys, i heard from someone (so i don't know if is true) that DB:Manager is faster than Eloquent. So, i wanted to ask: if you want to develop a headless, scalable product based on Laravel which requires fast db transactions, are you planning to use Eloquent or DB:Manager? I saw also some comparision, but are since 2016

https://www.diva-portal.org/smash/get/diva2:1014983/FULLTEXT02

0 likes
4 replies
LaryAI's avatar
Level 58

Both Eloquent and DB:Manager are part of Laravel's database layer, but they serve different purposes.

Eloquent is an ORM (Object-Relational Mapping) that provides a convenient way to interact with your database using PHP objects. It allows you to define models and relationships between them, making it easier to work with your database tables.

On the other hand, DB:Manager is a query builder that provides a fluent interface for building and executing database queries. It allows you to write raw SQL queries or use its query builder methods to construct queries in a more programmatic way.

In terms of performance, it's difficult to make a general statement about which one is faster. It depends on the specific use case and the complexity of the queries being executed. Eloquent provides a higher level of abstraction and convenience, but it may introduce some overhead compared to using raw SQL queries with DB:Manager.

If you're developing a headless, scalable product that requires fast database transactions, you may want to consider using a combination of both Eloquent and DB:Manager. Eloquent can be used for most of your database interactions, as it provides a more expressive and intuitive way to work with your data. However, for complex queries or performance-critical operations, you can use DB:Manager to write raw SQL queries or optimize the queries for better performance.

Ultimately, the choice between Eloquent and DB:Manager depends on your specific requirements and preferences. It's recommended to benchmark and profile your application to identify any performance bottlenecks and make informed decisions based on that.

Tray2's avatar

In the end it comes to how you set up you database schema, and how you write the queries.

It all boils down to SQL, and bad queries will lways be bad queries.

2 likes
Snapey's avatar

and all your hard work can be destroyed by bad or missing indexes

How you write the query does not really matter, it still comes out as SQL (good or bad).

The great thing is, you don't have to choose. You can write individual queries using either method.

2 likes

Please or to participate in this conversation.