Laravel query Constructor DB or ORM

What's the difference between the two, what's the scenario?

Reply content:

What's the difference between the two, what's the scenario?

All of our operations are walking ORM, because the operation is simple and intuitive, good maintenance, performance is low but not much lethal, there is a concurrency need to optimize the use of DB may not be able to solve the problem. Still need to understand the meaning of each method of ORM, or you may accidentally come out a lot more SQL, such as when the list to add a with do not rely solely on the relationship to get the other contents of the table.

Not used Laravel, but the understanding should be the same, DB is a direct write SQL Operations database, ORM is the use of object operations database.

SQL or ORM can operate the database, SQL is a relational database query language, and the relational database is the mainstream, the understanding and use of SQL is necessary. But program development is now more inclined to OOP, because it has more humane expression, and SQL is less expressive than OOP. The better expression of language, more conducive to human organization code logic, more expressive language in the overall development efficiency of quality optimization, code will be more robust, there may be fewer bugs.

Large sections of SQL to debug will not be easier than the ORM debugging, and ORM can generally switch between different databases, these are the advantages of ORM. Robust systems should also use ORM, which can effectively avoid low-level errors caused by mistakes. But the ORM code is not uniform, and you are familiar with its ORM in Laravel, not directly to other frameworks.

If you are not long in the profession, is a novice, that as much as possible with SQL, because SQL is unavoidable to use, the depth of understanding of SQL is necessary, multi-use can be regarded as practice. If you feel that you are already experienced, use an ORM, which can reduce the error rate.

It is recommended to operate the database directly with the DB façade because the ORM performance is low.

Data query above, ORM will not be worse than the DB, such as with, is using the most basic SQL Split statement optimization. The loss of ORM is just a code level, which is no longer a problem.

ORM is suitable for general to medium complexity queries, but also for various model operations, such as having a relationship targets, you can directly use targets ()->delete () and so on for relational data manipulation.
Soft deletion in ORM, Automatic Update Time field, field protection, field type conversion, will benefit you in some specification and system engineering.

Another DB scenario: some more complex query statements, transactional operations, and so on, need to be done in db.

The DB is primarily a query constructor (Sqlbuilder) that will help you transform input parameters into SQL statements to query the database, and you can write your own SQL statements manually.
ORM is an object-relational mapping (relational Mapper) tool that maps data from a database into objects and collection objects, and you can directly invoke mapped objects for development without touching the underlying data.

DB is suitable for projects with high performance requirements or simple business logic, and ORM is suitable for projects with complex business logic.

