Опять срачь за ORM

[metaclass]

http://tonsky.livejournal.com/275048.html

Если обработаться на жабе и дотнете, то записи в таблицах БД действительно начинают казаться объектами, только заколдованными злыми DBA по чернокнижию дейта и кодда. И нужно использовать специальные магические зелья в виде ORM чтобы объекты расколдовать.

А если работать в основном с СУБД и понимать, что "базе-то не объекты, в базе именно что отношения." то внезапно оказывается, что объекты-то не так часто и нужны, а иногда и вообще вредны.

Оно конечно выглядит просто - "взял из ORM объект, показал в форме, по нажатию ОК отдал его ORM на сохранение". Но подобные решения намертво увязывают структуру БД, результаты запросов и типы объектов в программе. И вынуждают использовать в БД только структуры данных, которые хорошо в такое укладываются.

Comments

[vit-r.livejournal.com]

Как уже писали по ссылке, манипулирование объектами позволяет подключать к проекту большое количество народа /не блестящих умственных способностей/ без боязни того, что они всё поломают.

[globalhvost.livejournal.com]

Не уверен. Думаю, манипулировать множествами/коллекциями отношений еще проще, чем управжняться с объектами.

[vit-r.livejournal.com]

Употреблять "думаю" в смысле "по моему мнению" в разговорах о других людях чревато. Тут помогает только опыт и натурный эксперимент.

[norguhtar.livejournal.com]

Не проще. Надо уже знать реляционную алгебру хоть в каком-то виде. В случае объектов программисту говорят отсюда это берешь отсюда то. Для него это более естественная модель.

[veremeenko-alex.livejournal.com]

Хм.

Ну вот захотели мы поменять название столбца и его тип в db (или наоборот сначала в ORM):
1. ORM ругнется и мы исправим в ORM
2. Проект не компилируется
3. Тупо просматриваем ошибки компилятора и исправляем код
4..
5. Профит

Как это в кложе? grep наше все? А что с типом? Смотреть эксепшены в рантайме?

[metaclass.livejournal.com]

В clojure с этим никак. Тестирование во все поля.
Динамическая типизация - хочешь, не хочешь, приходиться мириться.

[sergiej.livejournal.com]

Вот меня удивляет как вам не надоест всё это обговаривать в сотый раз. Как будто теоретики собрались и делают систему в космосе. В 99,99% выбор между вариантами архитектуры в области БД-ORM полностью продавливается "внешней" ситуацией, будь то уже нафигаченное "предками" в системе, требования клиента, в конце концов отсутствие 100 айседов и присутствие 200 индусов, которые с горем пополам что-то наковыряют, если им дашь готовые объекты и их массивы, но заклинятся наглухо, если им дашь что-либо функцональное.

[metaclass.livejournal.com]

Так задача внятно до сих пор не решена.
Потому что для ее решения требуются зависимые типы (== никаких 200 индусов, вместо них пару айседов).
А существующие решения - разной степени корявости и индусятины паллиатив.

[mikkim08.livejournal.com]

Потому что для ее решения требуются зависимые типы

А можно на пальцах показать и рассказать ?

[nivanych.livejournal.com]

> вместо них пару айседов

А вот это вы обманываете!
Чтобы яйседы пошли, да начали статическую типизацию пользовать?!

[globalhvost.livejournal.com]

А если доказать экономическую выгоду от использования нормального подхода (коллекции отношений) относительно метода с набором дешевой рабочей силы?

[sergiej.livejournal.com]

Ну попробуйте. Средний белорусский айсед минимум в два раза дороже индуса. Средний европейский айсед - в три. Для экономического обоснования надо доказать что айседы минимум в три раза быстрее сделают проект. Получится ли это? Может быть в идеальной конторе (ну не знаю, Гугле например) такое и бывает, в реальном мире "белая" европейская команда делает задачу в лучшем случае на 20%-30% быстрее, добавляется выше качество, что условно экономит ещё 10% на постпродакшн фиксах. В итоге - минус на фоне банды индусов. Если брать только лучших из лучших, которые сделают реально в два раза быстрее, то они будут стоить уже не в 3 раза, а в 5 раз дороже, и утянуть их у тебя будут пытаться все, в итоге гений уйдёт, а его код может поддерживать только он сам, потому что это будет не голимая джава, а что-то читаемое только после ведра вотки. Причём другой гениальный айсед с этим кодом разбираться не станет, он всё перепишет наново, потому что гении они абсолтны, и не используют чужой код, который в любом случае отстой для настоящего гения.

[guamoka.livejournal.com]

к этому надо еще присовокупить тот факт, что многие проекты 83% пишутся ради освоения бабла ради самого процесса написания проекта. вывод: выбор исполнителей и технологий самоочевиден:-)

[sergiej.livejournal.com]

И это тоже. Но я в таких стараюсь не участвовать. Поэтому приходится терпеть и айседов и всякие аджайлы :)

[sergiej.livejournal.com]

Кстати "взял из ORM объект, показал в форме, по нажатию ОК отдал его ORM на сохранение"
в кровавом энтерпрайзе это модель применима может в 10-20% случаев, в реальном мире в основном формы работают с адскими наборами объектов (в которых в зависимости от фазы луны и вчерашней погоды будут другие наборы полей), чтобы было веселее часть из них догружается из других систем/баз. В результате "ценность" ORM объекта как готового для работы понижается в разы.
С другой стороны у хардкорщиков поверх базы данных получается другие крайности, если их система работает не поверх одной базы данных, а в интегрированной среде с десятками систем. Они начинают беситься и требовать прямой доступ во все базы, требовать чтобы все эти базы были кошерным ораклом одной версии итп. Когда им фиг дают доступ они начинают придумывать уродские схемы с временными таблицами под каждую операцию на интерфейсах. Всё в итоге превращается в неподдерживаемый ад.
Правда чистый ORM тут не поможет никак, тут нужна модель данных поверх голого ORM

[norguhtar.livejournal.com]

Это у вас очень кровавый интерпрайз. А часто делают тут СУБД, тут СУБД по верх них ORM остальное тягается роботами обмена данными когда надо.

[sergiej.livejournal.com]

Это в меру стандартный энтерпрайз "роботы обмена данных" - пахнет 90-ми. Теперь все онлайн и риал тайм хотят.
Да я в курсе, что большинство банков живут ещё в 20-м веке. Что не есть плохо для них самих, но сложно если нужно поженить эту архитектуру с SOA.

[volodymir-k.livejournal.com]

хочется поговорить предметно и детально, но вы ж не оцените, завтра всё забудете и будете снова "ой ОРМ плохой, гадкий"
жанр "срачей" это бессмысленная трата времени жизни, и удовольствия интеллектуального никакого

если коротко, можно ответить так: "не нравится ОРМ -- не используй"

по делу, могу намекнуть идею: данные внутри БД и внутри клиента располагаются и обрабатываются по-разному в ЛЮБОМ случае
чем случай с ОРМ хуже непонятно каких альтернатив в непонятно каких случаях -- вам стоило бы сесть и глядя в зеркало самому себе в глаза написать эссе


Кстати за индусов белорусы зря переживают -- у них в полный рост сейчас идут курсы и скалы, и хаскеля, и R

[bydlorus.livejournal.com]

Пропал хаскель...

[thesz.livejournal.com]

За Хаскель я спокоен. Пропали индусы.

[sergiej.livejournal.com]

В основном народу не нравится что надо писать get... у многих просто святая война против геттеров и сеттеров. Потом мне показывают "свою разработку без ORM" где данные из таблиц загружаются в мапы. На мой вопрос, с каких пор это уже не объект, ответ "потому что".

[glorphindale.livejournal.com]

В народ десять лет вдалбливали, что надо писать геттеры и сеттеры. Вот маятник в другую сторону и качнулся.

[volodymir-k.livejournal.com]

да-да,
String userId = p.getUserId();
Number amount = p.getAmount();
p.setCode(PAID_CODE);

это ужас-ужас, а правильно

String userId = (String) p.get("UserId");
Number amount = (Number) p.get("Amount");
p.set("Code", PAID_CODE);

это ж совсем другое дело, никаких get/set... o wait...

[glorphindale.livejournal.com]

Если мы моделируем сущность без поведения и у нас статическая типизация, то нам достаточно структуры с прямым доступом к полям.
Если у нас динамическая типизация - касты лишние.

Плюс к тому, надо помнить, что 99.99% геттеров и сеттеров навсегда остаются тривиальными.

[volodymir-k.livejournal.com]

ваще агитаторов "за жизнь без ОРМ" стоило бы на полгода направлять на проект пользоваться ODBC API
желательно на GCC под линуксом с Ораклом

[ko-bx.livejournal.com]

Просто любители ORM (вроде меня) смотрят на базу данных как на деталь реализации персистентного хранилища для их моделей. Бизнес-логика вообще не должна подвязываться на БД и никак от неё явно не зависеть. Хотите -- выкиньте БД и храните всё в текстовых файликах.

То есть, "в идеале" вы начинаете писать всё на чистых объектах (тупо чистых объектах, в случае питона наследуемых от object), а затем "связываете" их с описанием БД (которое не является ORM, а это просто представляение вашей БД, собственно сама операция связывания и есть этот самый маппинг обджект рилейшнов). Sqlalchemy позволяет сделать именно это.

[serbod.livejournal.com]

У конкретных пацанов бизнес логика в самой БД сидит, и там простые и приятные ОРМы не работают. Только датасеты, только процедуры, только хардкор!

[anonim-legion.livejournal.com]

Да и память нынче дешева...

А давайте так - если объект потерялся, то есть изменение не отразилось в дисковом хранилище, то материальная ответственость за потерянный реальный объект ляжет на вас. А там и до уголовного дела недалеко.

[ko-bx.livejournal.com]

Что ты несёшь?

[anonim-legion.livejournal.com]

То, что в проектах, подразумевающих ответственность, работа идет строго с базой. UPDATE или INSERT прошел, транзакцию закомиттили - все, данные никуда не исчезнут.

Но поскольку в большинстве уеб-проектов данные никому не важны, да и сам проект нужен только для перепродажи следующему инвестору - то там можно наворачивать сто слоев абстракции, держать все в оперативной памяти и радоваться, как быстро персистируются объекты.

[ko-bx.livejournal.com]

Чушь какая-то. Может есть где-то туча подобных проектов, делающих это большинство, но меня как-то угораздило наблюдать большинство как раз тех, где данные важны (да я вообще не помню проекты, где данные не важны).

Чем ORM не подходит под определение "работа идет строго с базой"? Не понимаю, к чему ты.

[anonim-legion.livejournal.com]

>Хотите -- выкиньте БД и храните всё в текстовых файликах.

Кроссплатформенность - миф, бесшовный переход с базы на базу - тоже. Или оно одинаково медленно будет работать везде.

>да я вообще не помню проекты, где данные не важны
Да тот же Гугл. "Мы ни за что не отвечаем, пропадет что-то - сами виноваты".

[ko-bx.livejournal.com]

> Кроссплатформенность - миф, бесшовный переход с базы на базу - тоже. Или оно одинаково медленно будет работать везде.

Успешно переходил с базы на базу при помощи изменения пары строчек + миграции. По поводу "медленно" не понял, почему оно медленно будет работать.

> Да тот же Гугл. "Мы ни за что не отвечаем, пропадет что-то - сами виноваты".

Ну, одно дело "мы ни за что не отвечаем", другое -- "данные не важны".