Is it that bad to use an ORM?

Question

JavaScript

Hello everyone, I'm not very strong in the database, but I'm studying Django ORM in depth here and I'm wondering. Is it so bad to use an ORM and not write direct requests? I will say more, on a project where I had to write MySql queries myself, I also made a small ORM on my knee to make it easier and faster to work.

Are there any fat objective downsides to using an ORM? And what are the pros of using an ORM?

Answer 1

https://github.com/codrops/DiagonalSlideshow/

Answer 2

As long as your queries are simple and fit into the cases that the ORM creators have implemented, there will be solid pluses: developing faster, data is immediately displayed in the domain area, performance almost does not suffer.
But in the real world, such tasks are rare, more often queries look like "collect data piece by piece from half of all tables in the database, count it, aggregate it and display it in this form." If the ORM allows you to do this, then it usually does not in the most optimal way. And not infrequently, in such cases, you also have to fight with a very smart ORM ...
As an alternative to ORM, I would also look towards query builders, where monotonous things are well abstracted, but in which case you can write a piece in pure SQL. And the output is not a side effect in the form of a query to the database, but a string with SQL that can already be sent to the database, or saved to a file, or inserted into another query.

Answer 3

Considering that in many projects there are quite a lot of simple queries (selection by one table, insertion, update), it is convenient to use ORM for them. The only thing is, when you have relationships between entities, you should carefully monitor what requests are made to the DBMS and, most importantly, how many of them. For Django, there is a [django-debug-toolbar]( https://github.com/jazzband/django-debug-toolbar) that can track this.
Cons ORM - non-obviousness and lack of flexibility. For example, if I need to make a UNION of several tables, for a specific field of each of which make an alias (because the fields needed for sorting are named differently in them), by which to sort all the results, I think ORM will have to be abandoned. In real projects, unfortunately, such queries are encountered all the time, so instead of ORM it is more convenient to use query builders.
But in Django, a lot of things are tied to the built-in ORM, so it's hard to refuse it. I mean, if you do not use the built-in ORM in a Django project, then using Django in general does not make much sense.