"Pure" SQL in web projects

Question

SQL

For a long time I have been interested in the question, what is more often used in web projects? Pure SQL, or is ORM more common? I propose to exclude business card sites, hompags, etc. from the options under consideration.
If anyone can share the story of why he used one and moved on to the other, even better.

Answer 1

ORM only (and you can use the full power of SQL when you need it).
I think that in a fraction of a percent of projects (highload) you can use pure SQL, but in other cases it is not necessary, and you should prefer a more convenient and faster way: ORM.

Answer 2

I use it depending on the situation, when working with one ORM object is convenient and visual. Complex queries or ORM queries that eat up a lot of RAM or other resources in their purest form.

Answer 3

Both approaches are often encountered. Not infrequently both in the same project.
Both approaches were used. For simple things without an emphasis on performance - ORM, but not infrequently ORM makes inefficient SQL queries.
Now almost only ORM, which is demanding on performance, is no longer written in PHP.

Answer 4

Heavy selections - in stored procedures (MSSQL), and for simpler things - a good QueryBuilder with a wrapper for the db driver. I haven't seen pure SQL in code for a long time. The correct formatting of the request, parameters, connections, etc. should be shifted to the shoulders of other libraries. And yet, a good QueryBuilder creates an additional level of abstraction between the query and the database driver, so we get rid of it, and therefore it will even be possible to use another database, for example, SQLite instead of mssql

Answer 5

Pure SQL with multi-story queries is used where a significant part of the application logic is concentrated in the database. Such an application may have a web-based face, but it is not the same as a web-based application. Applications with logic in the database (i.e., manipulating data within the relational schema, and not I / O, peripherals, cache storage, etc.) are intranet applications that do not scale well between servers: accounting, billing, databases customers, inventory, etc.

Answer 6

If you create structures similar to "object-oriented", with data storage in the database, then it is more logical to use simple queries for the operation of such objects. Queries become more complex with the complexity of objects: an object includes many other objects, and in order to save time on accessing the database, it uses a complex query.
Also, complex queries can be required when compiling reports and other human-readable things.
Just try to keep things simple with these approaches. The simpler it is written, the easier it is to set up and the easier it is to control. And yes, speed wins.