Пыхотред

Мне удобней писать на языке, на котором я пишу, чем SQL. Например у меня manytomany связь entity - user, вместо

SELECT * FROM "auth_user" INNER JOIN "business_entity_users" ON ("auth_user"."id" = "business_entity_users"."user_id") WHERE ("business_entity_users"."entity_id" = (SELECT id from "entity" WHERE name="ЯНДЕКС") AND "auth_user"."username" = ph)

Я пишу

Entity.objects.get(name='ЯНДЕКС').users.filter(username='ph')

Получаю объект User, в котором я могу что-то изменить и сделать .save() вместо того чтобы ручками писать update.

SQL, конечно, далеко не эталон читабельности и лаконичности, но такой вариант несколько лучше:

SELECT * FROM auth_user u
JOIN business_entity_users b ON u.id = b.user_id
JOIN entity e ON b.entity_id = e.id
WHERE e.name='ЯНДЕКС' AND u.username = 'ph'

вместо ... Я пишу

Т.е. ты всегда отслеживаешь во что именно оттранслируется цепочка методов? Или тебе пофиг, пусть что хочет делает? А он такой вместо джойнов тебе выгребет n+1 запросов. Или наоборот, там где лучше бы джойнов избежать, соединит 10 таблиц.

Ну, в джанге можно нажать кнопочку и оно тебе покажет какие запросы выполнились на странице и сколько времени они занимали. https://raw.github.com/jazzband/django-debug-toolbar/master/example/django-de...

Поведние будут ли джоины или много запросов определяется наличием всяких select_related / prefetch_related.

В алхимии можно вообще можно явно это всё указывать.

Получаю объект User, в котором я могу что-то изменить и сделать .save()

Проблема многих ORM в том, что они реализуют только вещи, которые общие для разных баз. И поэтому невозможно выполнить SELECT ... FOR UPDATE на MySQL базе, например.

В алхимии это есть.

реализуют только вещи, которые общие для разных баз

Я выше кидал пример для оракла, аналогичные штуки для других баз.

Даже в django orm есть вещи типа https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/