LINUX.ORG.RU

Как постичь дзен по отношению к ORM?

 , ,


1

3

Думаю, все мы тут умеем писать SQL-запросы голыми руками. И тем не менее многие из нас при разработке используют или пытаются использовать те или иные библиотеки для ORM или Active Record.

Мы сейчас на работе пишем веб-приложуху на Питоне, и для ORM используем SQLAlchemy. SQLAlchemy была выбрана после того, как оказалось, что по паре критериев наша легаси-база совершенно, видите ли, непригодна для имеющихся абстракций в Django ORM. Ну окей, хорошо, что код всё равно только-только начали переписывать, так что смогли себе позволить быстро переделать написанные модели с Django на SQLAlchemy и дальше работать с ней. Ну окей, освоили её не очень привлекательный синтаксис построения запросов. И вот спустя некоторое время обнаруживаем очередную глухую стену. Специально не буду говорить, какую: я пока ещё не выяснил, возможно ли решить мою задачу средствами SQLAlchemy или нет, и не хочу быть дураком, утверждая, что невозможно.

Но факт в том, что я снова убиваю полдня на войну с грёбаным фреймворком – со штукой, которая должна упрощать написание запросов. Причём убиваю явно на пустом месте, потому что нужный мне запрос я бы уже давно написал руками, ну, разве что лень было перечислять нужные поля в селекте. Причём, как я уже сказал, есть ли свет в конце тоннеля, мне неведомо. Может, через ещё половину рабочего дня я решу проблему и успокоюсь, а может, после ещё целого дня пойму, что SQLAlchemy просто неспособна на нужный мне запрос.

Вопрос знатокам: доколе? Сколько настоящий, правильный, постигший дзен веб-разработки лоровец стал бы терпеть прихоти своего ORM-фреймворка? Выкинул бы в тот же миг, как потребовалось залезть глубже пяти страничек туториала и зубрить хитроспелетения методов вместо того, чтобы SQL в зубы и делом заниматься? Или выкинул бы в тот момент, когда провозился больше дня? Или изначально не стал бы брать, если точно знал (мой случай!), что в приложении будет что-то посложнее, чем простой CRUD без джойнов? Или терпел бы до последнего? Но где оно – последнее, после которого нужно признать, что фреймворк всё только портит?

И насколько (в процентах, в количестве запросов, в попугаях) допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

В общем, ЛОР, научи уму-разуму. Или подсунь что-нибудь почитать на эту тему. Только не про сам SQL – его-то я знаю на адекватном для конкретно моих задач уровне, – а именно про методологию, про умение выбирать или не выбирать инструменты, чтобы проект не превратился в месиво.



Последнее исправление: greatperson (всего исправлений: 2)

В общем, ЛОР, научи уму-разуму.

По-моему, вы - рукожопы, база у вас - кривая и джангу вы не знаете, видимо поэтому у тебя столько боли. Если ты полдня решаешь проблему с фреймворком - надо откатываться назад и учиться использовать свои инструменты :)

Alve ★★★★★
()
Ответ на: комментарий от Alve

база у вас - кривая

Факт.

Но изменять её структуру в ближайшее время нельзя, иначе бы и вопроса не было, всё было бы в разы понятнее, да.

greatperson
() автор топика
Последнее исправление: greatperson (всего исправлений: 2)
Ответ на: комментарий от outtaspace

Слишком часто, как это было в случае Вьетнама, потребность в дальнейшей поддержке некоторого курса действий обосновывается тем, что отказ от этого курса приведет к обесцениванию уже понесенных затрат – в случае Вьетнама понесенных военных потерь. Привычными становятся фразы «Мы настолько далеко зашли, что должны довести это дело до конца» и «Если мы сейчас повернем назад, то все наши жертвы окажутся напрасными».

Хорошая статья, автор правильно все понимает.

anonymous
()

ооп as usual оно хреново очень ложится на sql-домейн. Единственный вариант работать высокоуровнево с sql без протекающих абстракций с приемлемой производительностью это sql-dsl на лисповых языках, остальные варианты рано или поздно начинают выглядеть убого и от них приходится отказываться.

alienclaster ★★★
()
Ответ на: комментарий от Legioner

Соединений в потоках может быть хоть 10

Видимо, я мыслил в терминах тех архитектур серверов СУБД, с которыми имел дело в последнее время. Если так, то с этой точки зрения нормально. Ну ладно, я здесь не для холивара. Своё мнение высказал - и ладно.

den73 ★★★★★
()

допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

Даже не думай! Сейчас тебе кажется, что «вот тут всё можно сделать хитрым запросом, но на ORM это натянуть сложно» и ты лепишь этот запрос. Потом ещё запрос в другом месте, потом ещё... А потом вдруг тебе надо поменять логику работы и оказывается, что у тебя часть логики в модели, а часть выражается этими запросами, причём раскиданными хрен знает где. Лепить прямые запросы - всё равно что работать с полями объекта не через аксессоры, а напрямую - когда логика поменяется тебя ждут боль и страдание.

В общем, ЛОР, научи уму-разуму

Идея ORM в заключается в сохранении и загрузке объектов, а не в том, чтобы крафтить километровые запросы на update с 100500 join'ами и union'ами. Т.е. если тебе нужно что-то сложнее загрузки/сохранения - это ты должен реализовать в логике своего приложения, а не в запросе к БД.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Т.е. если тебе нужно что-то сложнее загрузки/сохранения - это ты должен реализовать в логике своего приложения, а не в запросе к БД.

Нет, у меня речь не об апдейте, а о сложном селекте. «Отчёт», как правильно сказали выше. Попытка формировать этот отчёт логикой в приложении обернулась чересчур долгой работой из-за всяких дополнительных запросов после основного.

greatperson
() автор топика
Ответ на: комментарий от greatperson

Попытка формировать этот отчёт логикой в приложении обернулась чересчур долгой работой из-за всяких дополнительных запросов после основного

Ну это не предметный разговор, можно предположить, что ты просто не осилил. Покажи хоть какой запрос в sql ты хочешь.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Не гони, ничто не мешает через ORM проводить сложные выборки из базы.

Goury ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.