Кодил лет 5 на PL/SQL большие проекты.
Потом покодил 4 года на C# и Java ещё бОльшие проекты, с возможностью сделать что-то и на PL/SQL. Никто не наседал с ООП догмами, никто не требовал писать только на Java...

Но я пришёл к тому, что пишу на Java + ORM + иногда триггеры + ручной фикс тех запросов, что ORM сгенерил неправильно. ИМХО такой подход реально удобнее. Когда знаешь и Java и PL/SQL и Hibernate и умеешь запросы оптимизировать - баланс между этими технологиями находится сам. Слишком много PL, отсутсвие ORM, неумение понять когда и что надо использовать - невежество, а не правильный архитектурный паттерн.

_модМаксим НВот тут все воюют, какой подход выбрать: ORM или DB'aware.
ООП был придуман для управления коллекциями объектов разных классов в ОП. Но если объекты уже находятся в БД, то и управлять ими надо средствами БД без ООП.

Ну зачем так категорично. Например, в моём приложении 70% всех запросов - примитивные CRUD операции, по первичному ключу. Почему бы мне не заюзать ORM для этих 70%? Ещё 20% это примитивные join-ы, с которыми ORM справляется и 10% сложные аналитические запросы, для которых я могу заиспользовать чистый DBMS-specific SQL.

maytonГхостикВообще, это тенденция, имхо.
Железо дешевеет, квалификация нет, поэтому выгоднее взять больше серверов и дешевле программистов.

Ну и опять же, языки, на которых пишут сервера приложений, развиваются, а pl/sql нет. Единственное его преимущество - это тесное сопряжение с sql. Который, в отношении работы с данными, всяческие hql пока еще обойти не могут.
Под давлением плачущей от незнаний SQL "Java/C# общественности", и от неженания изучать
принципы реляционной алгребры, под давлением современных трендов в строительстве
железа и дата-центров можно выделить следующие тенденции в разработке:
- изначальное проектирование любого приложения как "облачное". Принципиальное игнорирование алгоритмов и оптимизаций. Основная главенствующая идея - "облако всё разрулит и сбалансирует". А алгоритмы можно поскипать;
- изначальный отказ от любой логики на слое "storage";
- искуссвтенное навязывание браузера как универсального клиента для любых задач не взирая на технические ограничения самой задачи;
- искусственное включение в код целого пласта фреймворков и библиотек которые не нужны заказчику;
- засилие паттернов проектирования. Давление догм авторитетов разработки ООП. Игнорирование обычных инженерных идей экономии и оптимизации ресурсов.

А давайте мы будет вместе бороться против невежества, а не против ORM

_модПилот ПирксНапример, в моём приложении 70% всех запросов - примитивные CRUD операции, по первичному ключу. Почему бы мне не заюзать ORM для этих 70%?
А просто написать запрос без ORM что мешает ?
Кода больше + его надо поддерживать, если добавляется новое поле. Я на конференции разработчиков игр рассказывал про наши базы данных, в том числе про, что мы перешли с JDBC на Hibernate и довольны. После перехода наши DAO классы уменьшились суммарно примерно в 30 раз.

Сравните например слайд 20 и 21 http://www.slideshare.net/ssuserb52177/2013-skyforge

p.s. полная лекция, если интересно тут:

eevПилот Пиркс,

авторКода больше + его надо поддерживать, если добавляется новое поле.
поясните
Тобиш, если поле добавили, Hibernate сам узнает что поле добавилось, и нарисует его на какой-нибудь веб морде?
а при смене типа данных, сам заменит?
Нет.
Если мы добавляем поле в табличку нам надо сделать 100500 всего, в том числе протягивание в интерфейсы, в логику и в скрипт миграции базы вручную.

Плюс, в случае JDBC, надо поправить весь SQL, который затрагивает это поле. ORM избавляет нас только от этой небольшой части. В случае, если таблиц у нас 150+, то этот маленьй плюс становится большим плюсов. Вот и всё :)

VintПилот Пиркс,
не пробовали проектировать систему так, чтобы и запросы в базе хранились и собирались динамически из метаданных хранящихся в базе? тогда и jdbc вполне себе и патчи собираются из метаданных быстро.... все дело в подходе.
Не пробовал. Выглядит как тот же ORM только в базе а не Java. Какая разница?

_модВы просто спрятали часть кода :).
На самом деле нет. :) Если вы про инициализацию полей новыми значениями - то это не спрятано, просто в случае JDBC это происходит 2 раза. 1 раз в промежуточный объект, второй раз - биндинг в SQL.

_модзы добавление нового поля в таблицу не затрагивает приложения. Если конечно не писать select *
да ладно? а insert not null поля ? :)

_модНо я вас понял - вы используете ORM просто как средство автоподстановки, т.е. не по назначению
Ну пусть будет так :)