Так ли плохо использовать ORM?

Question

[DUDE]

Всем привет, в БД я не особо силен, но изучаю тут углубленно Django ORM и задаюсь вопросом. А так ли плохо использовать ORM и не писать прямые запросы? Скажу больше, на проекте, где приходилось писать самому запросы к MySql, я тоже делал маленькую ORM на коленке, чтобы было проще и быстрее работать.

Есть ли какие-то жирные объективные минусы использования ORM? И какие есть плюсы использования ORM?

Answer 1

[Дмитрий Беляев]

Пока Ваши запросы простые и вписываются в те кейсы, которые реализовали создатели ORM - будут сплошные плюсы: разрабатывать быстрее, данные сразу отображаются в доменную область, производительность почти не страдает.
Но в реальном мире такие задачи встречаются редко, чаще запросы выглядят как "собери данные по кусочкам с половины всех таблиц в базе, чето посчитай, с агрегируй и выдай вот в таком виде". Если ORM и позволяет такое делать, то делает как правило не самым оптимальным образом. И не редко в таких случаях приходится еще и бороться с очень умной ORM...
Как альтернативу ORM я бы еще посмотрел в сторону конструкторов запросов, где монотонные штуки хорошо абстрагированы, но в случае чего можно кусок написать на чистом SQL. И на выходе не сайд эффект в виде запроса к базу, а строка со SQL, которую можно уже отправить в базу, или сохранить в файлик, или вставить в другой запрос.

Comments

[Владимир]

В реальной жизни PL/SQL девелоперы писали процедуру, которая выполняла всю необходимую логику и выдавала результат в виде пайпа, а ява разработчики через ORM работали с этой процедурой как с обычной таблицей

[DUDE]

В той же Django ORM можно составлять цепочку запросов, получается все упирается лишь в скорость обработки и сложности запроса?

Answer 2

[Дмитрий Свиридов]

Учитывая, что во многих проектах достаточно много простых запросов (выборка по одной таблице, вставка, обновление), ORM для них использовать удобно. Единственное, когда у вас имеются связи между сущностями, следует внимательно следить за тем, какие запросы делаются к СУБД и главное, сколько их. Для Django есть [django-debug-toolbar](https://github.com/jazzband/django-debug-toolbar), с помощью которого это можно отслеживать.

Минусы ORM - неочевидность и недостаточная гибкость. Например, если мне нужно сделать UNION нескольких таблиц, для конкретного поля каждой из которых сделать alias (потому что нужные для сортировки поля называются в них по-разному), по которому выполнить сортировку всех результатов, думаю, от ORM придется отказаться. В реальных проектах, к сожалению, такие запросы встречаются сплошь и рядом, поэтому вместо ORM удобней использовать query билдеры.

Но в Django на встроенную ORM много чего завязано, поэтому отказаться от нее сложно. Я имею в виду, что если не использовать в проекте на Django встроенную ORM, то и использовать Django вообще особо смысла не имеет.