Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше.
Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.

А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Здравствуйте, Titus, Вы писали:


T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Для того чтобы не пилить руками простейшие запросы и не маппировать руками строки из выборки на объекты в коллекции. Сложные запросы — да, руками, особенно если с хинтами.
А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я, а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи.

T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна (контрагент ушёл с рынка, и тема, под которую заказывали софт, закрывается, а умеющие программисты всё полируют запросы "18й век, ручная работа").

Здравствуйте, Titus, Вы писали:


T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Личную глупость можно показывать и поскромнее! Сначала почитать тырнеты, посмотреть и сравнить код, а затем уже выходить на трибуну с кривенькой рожей "эй, тупари, чё эт вы тут ORM'ы какие-то используете!".

Здравствуйте, Философ, Вы писали:

Ф>Для того чтобы не пилить руками простейшие запросы
1) Так и в ORM тоже руками нужно работать.
2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example

Ф>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я,
Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.

Ф> а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи.
автотесты мне скажут, что не так, а не пользователи. Автотесты покруче компилятора будут.

Здравствуйте, Osaka, Вы писали:

O>Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна
Если я правильно понял твою мысль: "С ORM разработка быстрее".
Это был бы шах и мат, если бы это было бы правдой.

На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий.
На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому".
Прям хоть бери и под видеокамеру их сажай...

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, Titus, Вы писали:


T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

K>Личную глупость можно показывать и поскромнее! Сначала почитать тырнеты, посмотреть и сравнить код, а затем уже выходить на трибуну с кривенькой рожей "эй, тупари, чё эт вы тут ORM'ы какие-то используете!".

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

Здравствуйте, Titus, Вы писали:


T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют А чаще даже больше. ОРМ же позволяет сэкономить на этом. По итогу получается, что в большинстве случаев дбашники и не нужны, т.к. скорости хватает.
Их работа — это прийти, поругаться на криворкуих формошлёпов, настроить как нужно и уйти. Ну или сидеть на попе ровно, пиля базы в МГТС и прочих монстрах.

Здравствуйте, Titus, Вы писали:

T>На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий.
T>На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому".
T>Прям хоть бери и под видеокамеру их сажай...

Ну критерий простой — используем то, что решает задачу, и стоит меньше.
Если время (разработки+поддержки) с ORM превышает время без ORM, то спрашивается, нафига козе баян.
Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.

Буквально на прошлой неделе столкнулся с необходимостью перевести прогу с mssql на postgre. До этого такого опыта не было. Все заняло полдня, учитывая что чайник в этом вопросе. Установил другого провайдера, изменил строку подключения, создал базу из модели, экспорт импорт данных. Вуаля! Весь код остался прежним.

Здравствуйте, Titus, Вы писали:

T>Здравствуйте, Философ, Вы писали:

Ф>>Для того чтобы не пилить руками простейшие запросы
T>1) Так и в ORM тоже руками нужно работать.
T>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example

Я не говорил про работать мышкой. Ты вообще всё неправильно понял.
При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM.

Ф>>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я,
T>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.

Плохо смотрел. Туча запросов, типа "select something1, something2, something3 where id_something4 = ?" уходят под кат, а вместе с ними уходит под кат чтение полученных значений в поля объектов. А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.

Ф>> а особенно при изменении в структуре БД: после перегенерации модели тебе компилятор скажет что не так, а не пользователи.
T>автотесты мне скажут, что не так, а не пользователи. Автотесты покруче компилятора будут.

Автотесты ещё писать нужно — это время, это внимание => это ошибки.

Здравствуйте, Titus, Вы писали:


T>Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше.
T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.

T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Плюсы ORM:
— быстрая разработка — DAO генерятся "сами".
— низкие требования к квалификации программистов — SQL знать не надо, сложные DAO для обновления и удаления данных из множества таблиц писать не надо.
— упрощение архитектуры системы — работа с базой сводится к "загрузил мегаобъект" и "сохранил мегаобъект".
— независимость от базы данных (для большинства приложений сомнительный плюс)

Минусы ORM:
— медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов.
— медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно.
— низкое быстродействие как следствие всех перечисленных плюсов.

Здравствуйте, scf, Вы писали:

scf>- медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов.

В тех ситуациях, когда они сломают ORM, они сломают и код с любым другим подходом.

scf>- медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно.

Нормальные ORM поддерживают вариант native query с маппингом на объекты. Это решает проблемы большинства нетривиальных запросов.

scf>- низкое быстродействие как следствие всех перечисленных плюсов.

Эти "плюсы" — следствие изначально кривого дизайна приложения: если вы завели мегатаблицу для мегаобъекта, то она останется таковой при любом подходе. С другой стороны ORM (как и более низкоуровневый подход) позволяет выбрать какую часть объекта вы хотите видеть и работать только с ней.

Здравствуйте, Titus, Вы писали:

T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Чтобы код работы с БД был типизированным. Мало?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Titus, Вы писали:

T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

НС>Чтобы код работы с БД был типизированным. Мало?

Для типизации кортежей достаточно MyBatis какого-нибудь, или даже примитивных DbUtils.
Типизация запросов — спорная тема. Без метапрограммирования — громоздко, с ним — непрозрачно.

Так стоит ли овчинка выделки, действительно?

Здравствуйте, Философ, Вы писали:

Ф>>>Для того чтобы не пилить руками простейшие запросы
T>>1) Так и в ORM тоже руками нужно работать.
T>>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки запросов типа Query-By-Example

Ф>Я не говорил про работать мышкой.
Ты говорил про «не пилить руками простейшие запросы»

Ф> Ты вообще всё неправильно понял.
Возможно, но откуда ты знаешь, что я понял?

Ф>При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM.
Каков слог! ) А чем отличается «хардкодятся» от «пишутся с использованием ORM»?

T>>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.
Ф>Плохо смотрел. Туча запросов, типа "select something1, something2, something3 where id_something4 = ?" уходят под кат, а вместе с ними уходит под кат чтение полученных значений в поля объектов. А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.

А теперь следите за руками! Все что нагенерировала ORM, доступно для редактирования руками. И поскольку автоговнокод далек от оптимального, возникает желание, а главное, необходимость подредактировать автоговнокод руками.
А теперь внимание вопрос: после «доработки напильником» что перегенерирует ORM?

Ф>Автотесты ещё писать нужно — это время, это внимание => это ошибки.
Ну это отдельный топик: «Зачем нужны автотесты?» — этот вопрос, кстати, у меня не возникает. Затраты на автотесты на моей практике окупаются (в деньгах) уже на третьем регрессионном тестировании.

Здравствуйте, bnk, Вы писали:
bnk>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.
Вот бы где вменяемый пруф найти...

Здравствуйте, Rhino, Вы писали:

R>"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют
1) database administrator — не программист.
2) Плохо тот программист, кто не знает ЯМД.

Здравствуйте, s_aa, Вы писали:

_>Буквально на прошлой неделе столкнулся с необходимостью перевести прогу с mssql на postgre. До этого такого опыта не было. Все заняло полдня, учитывая что чайник в этом вопросе. Установил другого провайдера, изменил строку подключения, создал базу из модели, экспорт импорт данных. Вуаля! Весь код остался прежним.

Лет 10 назад решал аналогичную задачу (тоже на PostgreSQL), без ORM. Вся заняло меньше часа.
1) Создал скрипт БД источника
2) Накатил скрипт на новую БД в PostgreSQL (насколько помню в текстовом редакторе пришлось несколько раз нажать Ctrl+H)
3) Поменял коннект в конфигурационном файле приложения
4) Смигрировал данные 1в1.
Вуаля!

Здравствуйте, scf, Вы писали:

scf>- низкие требования к квалификации программистов

Вот тут как раз и вопрос: если ты высококвалифицированный программист, что тебе даст ORM?

Без ссылка на ORM: если куча ПТУшников взялась за дело, то хороший продукт эта "могучая" кучка превратит в г*вно, а если за г*вно возьмется, то только времени потратит меньше.

scf>- упрощение архитектуры системы — работа с базой сводится к "загрузил мегаобъект" и "сохранил мегаобъект".
Вот не заметил. Если архитектура сложна в структуре БД, то и в модели объектов приложения она не будет простой.

scf>Минусы ORM:
scf>- медленные доработки: код с ORM хрупок, изменения в модели или сервисном слое могут сломать сохранение объектов.
scf>- медленные доработки: ORM очень сложен, исправлять проблемы в приложении или делать что-то нетривиальное очень трудозатратно.
scf>- низкое быстродействие как следствие всех перечисленных плюсов.

А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц.
Жуткие противоречия в данных, двойной/тройной ввод пользователей и прочие прелести паттерна "лебедь рак и щука".