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

[metaclass]

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

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

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

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

Comments

[vit-r.livejournal.com]

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

[veremeenko-alex.livejournal.com]

Хм.

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

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

[sergiej.livejournal.com]

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

[sergiej.livejournal.com]

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

[volodymir-k.livejournal.com]

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

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

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


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

[ko-bx.livejournal.com]

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

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