Кодил лет 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+, то этот маленьй плюс становится большим плюсов. Вот и всё :)