Еще одна статья ни о чем… Парень поймал удачу за хвост и вывалил свои эмоции в мир, да только толку? 900 слов — и ни крупицы полезной информации. Да, отличная позитивная статья для уютной ЖЖ-чки: прочитал, воодушевился — и забыл. Но при чем тут Хабр?
И не надо думать, что я просто пессимист и брюзга, ненавидящий дух стартапов. Я уже третий запустил, и развиваю потихоньку, поэтому и заинтересовался, что за интересная статья. Да только зря время потратил…
Ясно, спасибо за разъяснение. А можете пояснить насчет "слишком большой ради пары сущностей"? Из личного опыта: я Hibernate применял (и применяю) не только в классических Enterprise-ах, но и микро-проектах, типа утилит, причем некоторые даже для разовых задач. Вполне себе удобно, в любом случае, лучше, чем вручную из ResultSet-ов JDBC вытаскивать данные в свою логику и обратно. Более того, однажды получил мощную оптимизацию, даже сначала не заметив ее, когда Hibernate без указаний с моей стороны применил пакетные обновления сущностей в СУБД. На Ваш взгляд, что именно в Hibernate большое и тяжелое, и на что негативно влияет эта тяжесть?
Я и еще пара моих знакомых не умеем «готовить» Hibernate и поэтому точно знаем, что Hibernate — гуано. Поэтому мы решили помучаться с Ebean и сделали вот так вот нечто для чего-то. Теперь мы знаем, что Ebean — это круто, потому что хипстер, а Hibernate — все равно гуано, потому что «потому что»
Хорошая статья для тех, кто хочет познакомиться с Ebean. Но, на мой взгляд, Ваше мнение о Hibernate лучше бы вообще не упоминали…
Похоже, что вы мыслите понятиями конкретно вашей специфики. Видимо, у вас т.н. high load проект(ы) в котором(ых) приходится работать с большим количеством данных, находящихся в ОЗУ. Да, для этого нужны вышеперечисленные знания, и поэтому ваши архитекторы в них «как рыба в воде». Но, во-первых, даже high load бывает разный, а во-вторых далеко не каждый второй проект в стране — это high load… Вам при собеседовании, видимо, надо спрашивать про алгоритмы, но мы же обсуждаем сферическое собеседование в вакууме, срез «в среднем по больнице», поэтому мне кажется, что ваши требования совсем не средние…
лучше брать спокойных, безинициативных, способных к рутине
Хорошая команда должна состоять из людей различных психотипов/ролей. Есть исследования по этому поводу и тесты соответствующие. Так что неправы ни вы ни компания, т.к. в команде должны быть и те и другие типы людей, и еще несколько других…
Выдающийся показатель, это например 10 000 запросов в секунду
Запрос запросу — рознь, так что не стоит вот так вот огульно под одну гребенку… К тому же это просто пример, в надежде донести мысль о том, что как я считаю, знание алгоритмов мало говорит о том, что представляет из себя разработчик. И даже наоборот, раз он так тщательно готовился к собеседованию и штудировал давно забытую теорию, то может с практикой у него туговато… Большинство студентов знает такие алгоритмы лучше, чем большинство синьоров и архитекторов, но говорит ли это о том, что студент лучше справится с реальным проектом?
Так я о том речь и веду — в большинстве случаев и знать этого не надо, т.к. «большинство случаев» — это структура из сотни-другой элементов, обращения к которой выполняются реже раза в секунду, в однопоточной среде. В таких условиях не имеет значение «как устроены стандартные структуры данных»… А если требуется работать с большими долгоживущими массивами, которые читаются/изменяются тысячи раз в секунду да еще и в конкурентной (многопоточной) среде, то тут, конечно, стоит поинтересоваться внутренней реализацией, и, возможно даже, реализовать свою.
НО! В разрезе темы статьи — лично я бы предпочел узнавать/разрабатывать низкоуровневые алгоритмы только когда текущая решаемая задача этого требует, а не просто теоретически знать (и помнить всю жизнь), чтобы на собеседовании блеснуть знаниями, которые пригодятся с вероятностью менее 1%…
Возможно, что конкретно в Вашем проекте, действительно часто. Но, готов побиться об заклад, в абсолютном большинстве среднестатистического ПО такие проблемы возникают чрезвычайно редко…
не представляете себе, какие кадры «с опытом от 10 лет» встречаются
я, например, такой «кадр», и я не смогу написать пузырьковую сортировку даже на псевдокоде, т.к. не знаю принципа ее работы. И это несмотря на то, что лет 15 назад я точно знал как она работает. За «от 10 лет» практики на промышленных проектах (Один, например, из более сотни серверов, раскиданных по стране. Другой — обрабатывает более 1 млн. SOAP-запросов в сутки, имея при этом десятикратный запас производительности) мне ни разу не пригодилось знание низкоуровневой реализации списков и сортировок…
Возможно, Вы на собеседовании посчитаете мой опыт «неправильным», и ненужным, или подумаете что я про опыт лгу, раз не могу «изобразить» пузырьковую сортировку. Практически все мои коллеги (в т.ч. и бывшие) так не считают. Вопрос — кто прав, Вы с теоретическими вопросами или коллеги, знающие что я могу на практике?
Насчет фич 8-ой java и дергания логики из View — на мой взгляд не очень хорошая идея
Ну, логика — понятие растяжимое, даже в вашем примере person.id вполне мог бы быть default методом какого-нибудь интерфейса Identifier, например, при каждом обращении к getId генерирующим новый сиквенс, чисто теоретически…
По поводу технологий — вечный холивар, у каждой есть плюсы и минусы, не будем об этом. Но вот по поводу JSP — мне кажется, что довольно тяжело расписывать для каждой странички каждый тег. Либо ваша Admin Panel выглядит очень убого, либо на каждую страничку у вас исходники на много сотен строк, либо у вас не чистый JSP, а подключена какая-то библиотека виджетов. Насколько я помню, на заре JSF нередко View рисовался именно на JSP-странице. В общем, чисто из любопытства, скажите, что представляет из себя ваша Admin Panel: много ли страничек, каков внешний вид, какой объем кода типичной странички?
Мне в последние годы казалось, что Server Pages — сильно устаревшая технология, т.к. все тонкие клиенты для JEE, с которыми сталкивался (существующие или которые начинал с нуля сам) делались на JSF либо GWT. Да и вообще, за 10+ лет разработки на Java ни разу не видел JSP в качестве основного инструмента «рисования» View. Мне вот интересно, кроме примера в статье, у Вас реальные JEE проекты крутятся на JSP/SSP?
По поводу перехода на Java 8. Есть у меня проект на Java 7, Tomcat 7, MySQL, JSF, Hibernate. Попытался переключиться на Java 8, вроде без проблем. Попытался тут же применить что-то новое, нашел подходящую структуру, в которую «просился» default метод интерфейса. Переделал, запустил, но — увы — реализация EL на JSF страничке, которая раньше «понимала» метод в абстрактном классе, не нашла тот же метод в интерфейсе. Ну понятно, думаю, 7-й Tomcat восьмую Java не поддерживает, надо 8-й Tomcat попробовать (библиотека EL идет в комплекте с Tomcat-ом). Ставлю 8-й Tomcat, который как оказалось стартует вдвое дольше 7-го, и вижу, что ничего не изменилось — та же ошибка. Дальше копать не стал, т.к. в моем случае овчинка выделки не стоит… И, кстати, поиграйтесь с фичами Java 8 на JSP страничке, вполне вероятно, что интерпретатор JSP тоже «сломается», как и парсер EL…
Мне кажется, что автор прав в том, что фреймворки — палка о двух концах, и, прежде чем использовать их, следует 7 раз отмерить, насколько плюшки фреймворка покрывают его тяжесть, ограничения и требования изучения его специфики. У меня, например, сейчас в поддержке проект с Seam, в котором не «5 мегабайт библиотек», а 35, причем реально используется в лучшем случае 3-5% их возможностей. Можно было сделать все то же самое, но без Seam (и того, что тянется с ним в зависимостях) вообще…
С другой стороны, всем понятно, что с нуля писать всё — разве что в качестве «поиграться» пока не надоест либо в маленьких проектах. Лично мне нравится пользоваться не фреймворками, «окружающими» мое приложение (т.е. моё приложение внутри фреймворка), вместо этого предпочитаю, чтобы фреймворки были внутри приложения. Т.е., использую только утилитарные вещи, которые подключаются и делают какую-либо ограниченную часть функций, по возможности не затрагивая другие слои приложения. Например, классический Hibernate берет на себя всю работу с БД, и заставляет разбираться с его спецификой только для операций с базой. При этом, например, получив при его помощи объект считанный из БД, при дальнейших операциях с этим объектом, про Hibernate можно забыть.
Несмотря на то, что тема статьи в общем и целом актуальна, конкретные примеры, на мой взгляд «ни о чём» — просто некий код, которого в любом проекте море. Ценность статьи, на мой взгляд — 0, комментарии полезнее и информативнее, чем статья…
Ну вот, не прошло и дня, как в очередной раз убедился в том, что путь contract last не так плох, как его малюют. Только что пришли претензии от разработчиков сторонней компании к XSD нашего веб-сервиса, который разрабатывался одним из наших программистов по принципу contract first. Пишут что необязательный по бизнес-логике элемент, в XSD указан как обязательный (minOccurs=«1»). Наш программист уже уволился, поэтому сам посмотрел XSD — ничего подобного, нет такого свойства у элемента, и решил их послать отклонить претензию. Но решил сначала поискать какое значение по-умолчанию по спецификации. Оказалось — точно, если не указан явно, то принимается minOccurs=«1», ошибка наша. Программист, не особо вдаваясь в подробности спецификаций, нарисовал в XSD имена и типы элементов, а обязательность не указывал явно нигде.
Посмотрел тут же для примера свои XSD-шки, сгенерированные с исходников — всё учитывается, для необязательных полей minOccurs=«0». Правда, если уж быть до конца честным, в исходниках обязательность мной задавалась явно, т.е., если бы тоже не вдавался в подробности, то наступил бы на те же грабли…
У кого как, моя практика показывает, что независимо от наличия/отсутствия ТЗ, веб-сервисы (как и любой другой функционал) имеют свойство со временем развиваться/изменяться. Не все, и не так часто, как внутренняя реализация Системы, но факт имеет место быть, и неоднократно.
Во всех них нельзя просто так взять и написать wsdl
Да-да, я уже лет 8 постоянно сталкиваюсь с разработкой/доработкой веб-сервисов, но до сих пор в WSDL/XSD чувствую себя неуверенно. Мне кажется, что даже многие из тех, кто использует contract first, не смогут с нуля нарисовать WSDL-описание, никуда не подглядывая…
Поддерживаю. Я не согласен с тем, что contract first — это абсолютное добро, предпочитаю contract last, и не только потому, что разработчику обычно удобнее писать код, а не XML. У меня, например, часто объекты веб-сервиса замаплены еще и на СУБД, за счет чего, сущность считанная Hibernate-ом из БД без каких-либо модификаций и копирования, как есть отдаётся движку веб-сервисов на сериализацию в XML. Генерация же с WSDL обычно на корню убивает принципы ООП. Это, конечно, классы из которых создаются объекты, но такие недообъекты нельзя трогать, т.к. при доработке сервиса они будут сгенерированы заново, и все мои плюшки исчезнут. Простейший пример в продолжение связки Hibernate->XML: обычно Hibernate-сущности в проекте наследуются от какого-нибудь Identitfier, при перегенерации extends «слетит».
В общем и целом, лично мне намного удобнее и приятнее писать хорошо структурированный Java код, а потом генерировать из него WSDL, а не наоборот — генерировать в отдельный пакет кучу псевдо-объектного мусора из классов, которые потом кувалдой внедряешь в логику Системы. Спасибо за статью, буду пробовать…
акторы хороши для программирования многопоточных примитивов
В приведенном примере Batcher я не вижу никаких синхронизаций, а BatcherDemo, кроме того, что однопоточный, еще и Thread.sleep постоянно вызывает. Что будет, если передача запросов Batcher-у будет многопоточной и высококонкурентной? Могут ли сразу 10 потоков войти в Batcher.onMessage и одновременно пройти проверку argList.size() == 1, что приведет к тому, что после того, как все 10 запросов будут обработаны, lastTimer.send(«KILL») так и не будет вызван? Если GPars где-то внутри не синхронизирует потоки, то многопточность в приведенном примере, видимо, не работает? Или я неправ?
Я коренной астанчанин. Ваш друг то ли шутник, то ли в командировке так на печень надавил, что новости от белочки узнаёт. Да, мы шокированы таким резким падением теньге, но жизнь как шла, так и идет своим чередом.
"На больших объемах данных" вообще ВСЁ следует делать осторожно, "да и на маленьких тоже" ;) Опять же личный опыт: пару месяцев назад промышленный сервер приложений начал грузить СУБД под 100%, в конце-концов «съев» долгими (от нескольких секунд до 10-20 секунд каждый) запросами все свободные соединения к БД. Когда начали разбираться, оказалось, что один из разработчиков, создав кучу индексов в тестовой базе, забыл добавить в сборку скрипт на создание одного из них. Отсутствие одного только индекса «положило» критичную промышленную Систему, причем на запросах к маленькой по меркам Oracle таблице (200-300 тысяч записей). Имеет ли это какое-то отношение к ORM? Нет, т.к. база нагружалась еще до того, как дело доходило до выборки Hibernate-ом «неоптимальных» каскадных данных.
"усугубляется при использовании JPA на кластере" — даже не знаю, к чему Вы это. Я две легаси Системы переводил на кластерную конфигурацию, и не припомню, чтобы были проблемы с ORM. Вообще, ни одной проблемы, по крайней мере, появившейся именно из-за перехода на кластер. Да, конечно, пришлось менять логику, делать синхронизацию, но подвохов от ORM не было, т.е., если бы Hibernate не применялся в проекте, переход не стал бы проще или быстрее.
"лишь 5-10% разработчиков серверного кода понимают и умеют" — только в этом и кроется главная проблема с производительностью СУБД. Ни конкретный язык программирования, ни применение/отсутствие ORM не играют столь же ощутимой роли, как степень «кривизны рук» разработчика.
PS Насчет широко распространенного мнения о том, что ORM неоптимально выбирает из БД кучу ненужной информации: если ваша бизнес-логика сделана так, что, например, для отображения списка каких-либо документов требуются данные из 10-ти таблиц, то хоть с ORM, хоть без него — вам таки придется вытащить эту «кучу ненужной информации» и показать пользователю. Поэтому, проблемы повышенной нагрузки на СУБД гораздо эффективней решать пересмотром логики/архитектуры Системы, а не плевками в сторону ORM. Если переиначить известную народную мудрость: плохому программисту ORM мешает… ;)
Согласен, ORM подталкивает к неэффективному использованию ресурсов СУБД. И, да — бывают неявные побочные эффекты и ошибки фреймворков (у себя в блоге не так давно писал об этом). Но, как мне кажется, главная задача ORM — чистота кода, к сожалению, нередко за это приходится платить ресурсами СУБД. Но ведь апгрейд даже фирменного «железа» стоит меньше, чем оплата труда программистов. Я потому и писал про личный опыт с объемами данных — в большинстве случаев (по крайней мере, в моей практике) можно пренебречь двух-трехкратным увеличением нагрузки на СУБД, в угоду чистоте кода, который легче поддерживать.
Вообще, насчет производительности СУБД мне понравилась фраза, которую написали в анонсе JBoss DataGrid. Это технология распределенного кеширования данных, и они написали о том, что она может сильно пригодиться тем, у кого нет нормальной СУБД (не дословно, но смысл примерно такой). Я это к тому, что Enterprise проекты (которые очень любят ORM) обычно крутятся на серьезных СУБД, например, Oracle. Я не специалист по СУБД, и ничего не рекламирую, но с Oracle я не включаю даже базовых функций кеширования, встроенных в Hibernate потому, что уверен на 100% в том, что Oracle гораздо лучше знает что и как кешировать.
По поводу ваших проблем с джойнами и прочими сложными запросами: лично я никогда не формирую сложные запросы на языке ORM (в моем случае Hibernate-овский HQL). В Hibernate отличная поддержка native query: можно отдать Hibernate-у чистый SQL, а получить в ответ замапленные сущности (т.е., те же, что вернул бы HQL).
Насчет Вашего последнего абзаца — очень, очень спорное заявление. То, что "в состоянии написать любой java-программист", должен будет когда-то поддерживать и дорабатывать другой java-программист, и с почти 100% уверенностью можно сказать, что проклятий в сторону первого будет немало. ORM, кроме непосредственно технологий, являются еще и неким подмножеством языка, знакомым большинству программистов в отрасли. Когда приходит новый человек на проект и видит Hibernate, у него вряд ли возникнет вопрос «зачем это здесь», а вот если он видит очередной велосипед… Опять же, на личном опыте: 10 лет назад, когда я был совсем джуниор, старший программист решил внедрить ORM в один из общих модулей проекта. Я тогда разве что головой об стол не бился, пытаясь понять какой велосипедист придумал Hibernate, а потом проникся. Я сейчас даже в микропроектах его использую, очень удобно…
Да, я Java программист, думаю по комментариям это сразу бросается в глаза :)
Я считаю, что автор статьи абсолютно неправ, связывая незнание SQL/принципов работы СУБД и какой-либо конкретный язык программирования (а переводчик неправ, защищая его точку зрения).
Мне не раз встречались, например, системные администраторы, не имеющие никакого отношения к программированию, которые одним простым запросом давали нагрузку на базу в тысячи раз большую, чем любой запрос, отправляемый из ПО. Любимая ошибка многих — в условии ограничения выборки взять в кавычки значение, накладываемое на числовое поле (или наоборот). Результат: мало того, что индексы не работают, так еще и выполняется конвертация значений поля во всех записях таблицы.
Похожая ошибка у программистов — при накладывании ограничений по дате применять функцию приведения значения не к передаваемому условию, а к полю в БД: вместо "to_date(моё_значение) = поле_таблицы" делать "моё_значение = to_чтонибудь(поле_таблицы)".
И не надо думать, что я просто пессимист и брюзга, ненавидящий дух стартапов. Я уже третий запустил, и развиваю потихоньку, поэтому и заинтересовался, что за интересная статья. Да только зря время потратил…
Хорошая статья для тех, кто хочет познакомиться с Ebean. Но, на мой взгляд, Ваше мнение о Hibernate лучше бы вообще не упоминали…
Хорошая команда должна состоять из людей различных психотипов/ролей. Есть исследования по этому поводу и тесты соответствующие. Так что неправы ни вы ни компания, т.к. в команде должны быть и те и другие типы людей, и еще несколько других…
НО! В разрезе темы статьи — лично я бы предпочел узнавать/разрабатывать низкоуровневые алгоритмы только когда текущая решаемая задача этого требует, а не просто теоретически знать (и помнить всю жизнь), чтобы на собеседовании блеснуть знаниями, которые пригодятся с вероятностью менее 1%…
Возможно, Вы на собеседовании посчитаете мой опыт «неправильным», и ненужным, или подумаете что я про опыт лгу, раз не могу «изобразить» пузырьковую сортировку. Практически все мои коллеги (в т.ч. и бывшие) так не считают. Вопрос — кто прав, Вы с теоретическими вопросами или коллеги, знающие что я могу на практике?
По поводу технологий — вечный холивар, у каждой есть плюсы и минусы, не будем об этом. Но вот по поводу JSP — мне кажется, что довольно тяжело расписывать для каждой странички каждый тег. Либо ваша Admin Panel выглядит очень убого, либо на каждую страничку у вас исходники на много сотен строк, либо у вас не чистый JSP, а подключена какая-то библиотека виджетов. Насколько я помню, на заре JSF нередко View рисовался именно на JSP-странице. В общем, чисто из любопытства, скажите, что представляет из себя ваша Admin Panel: много ли страничек, каков внешний вид, какой объем кода типичной странички?
По поводу перехода на Java 8. Есть у меня проект на Java 7, Tomcat 7, MySQL, JSF, Hibernate. Попытался переключиться на Java 8, вроде без проблем. Попытался тут же применить что-то новое, нашел подходящую структуру, в которую «просился» default метод интерфейса. Переделал, запустил, но — увы — реализация EL на JSF страничке, которая раньше «понимала» метод в абстрактном классе, не нашла тот же метод в интерфейсе. Ну понятно, думаю, 7-й Tomcat восьмую Java не поддерживает, надо 8-й Tomcat попробовать (библиотека EL идет в комплекте с Tomcat-ом). Ставлю 8-й Tomcat, который как оказалось стартует вдвое дольше 7-го, и вижу, что ничего не изменилось — та же ошибка. Дальше копать не стал, т.к. в моем случае овчинка выделки не стоит… И, кстати, поиграйтесь с фичами Java 8 на JSP страничке, вполне вероятно, что интерпретатор JSP тоже «сломается», как и парсер EL…
С другой стороны, всем понятно, что с нуля писать всё — разве что в качестве «поиграться» пока не надоест либо в маленьких проектах. Лично мне нравится пользоваться не фреймворками, «окружающими» мое приложение (т.е. моё приложение внутри фреймворка), вместо этого предпочитаю, чтобы фреймворки были внутри приложения. Т.е., использую только утилитарные вещи, которые подключаются и делают какую-либо ограниченную часть функций, по возможности не затрагивая другие слои приложения. Например, классический Hibernate берет на себя всю работу с БД, и заставляет разбираться с его спецификой только для операций с базой. При этом, например, получив при его помощи объект считанный из БД, при дальнейших операциях с этим объектом, про Hibernate можно забыть.
Несмотря на то, что тема статьи в общем и целом актуальна, конкретные примеры, на мой взгляд «ни о чём» — просто некий код, которого в любом проекте море. Ценность статьи, на мой взгляд — 0, комментарии полезнее и информативнее, чем статья…
их послатьотклонить претензию. Но решил сначала поискать какое значение по-умолчанию по спецификации. Оказалось — точно, если не указан явно, то принимается minOccurs=«1», ошибка наша. Программист, не особо вдаваясь в подробности спецификаций, нарисовал в XSD имена и типы элементов, а обязательность не указывал явно нигде.Посмотрел тут же для примера свои XSD-шки, сгенерированные с исходников — всё учитывается, для необязательных полей minOccurs=«0». Правда, если уж быть до конца честным, в исходниках обязательность мной задавалась явно, т.е., если бы тоже не вдавался в подробности, то наступил бы на те же грабли…
Да-да, я уже лет 8 постоянно сталкиваюсь с разработкой/доработкой веб-сервисов, но до сих пор в WSDL/XSD чувствую себя неуверенно. Мне кажется, что даже многие из тех, кто использует contract first, не смогут с нуля нарисовать WSDL-описание, никуда не подглядывая…
В общем и целом, лично мне намного удобнее и приятнее писать хорошо структурированный Java код, а потом генерировать из него WSDL, а не наоборот — генерировать в отдельный пакет кучу псевдо-объектного мусора из классов, которые потом кувалдой внедряешь в логику Системы. Спасибо за статью, буду пробовать…
"усугубляется при использовании JPA на кластере" — даже не знаю, к чему Вы это. Я две легаси Системы переводил на кластерную конфигурацию, и не припомню, чтобы были проблемы с ORM. Вообще, ни одной проблемы, по крайней мере, появившейся именно из-за перехода на кластер. Да, конечно, пришлось менять логику, делать синхронизацию, но подвохов от ORM не было, т.е., если бы Hibernate не применялся в проекте, переход не стал бы проще или быстрее.
"лишь 5-10% разработчиков серверного кода понимают и умеют" — только в этом и кроется главная проблема с производительностью СУБД. Ни конкретный язык программирования, ни применение/отсутствие ORM не играют столь же ощутимой роли, как степень «кривизны рук» разработчика.
PS Насчет широко распространенного мнения о том, что ORM неоптимально выбирает из БД кучу ненужной информации: если ваша бизнес-логика сделана так, что, например, для отображения списка каких-либо документов требуются данные из 10-ти таблиц, то хоть с ORM, хоть без него — вам таки придется вытащить эту «кучу ненужной информации» и показать пользователю. Поэтому, проблемы повышенной нагрузки на СУБД гораздо эффективней решать пересмотром логики/архитектуры Системы, а не плевками в сторону ORM. Если переиначить известную народную мудрость: плохому программисту ORM мешает… ;)
Вообще, насчет производительности СУБД мне понравилась фраза, которую написали в анонсе JBoss DataGrid. Это технология распределенного кеширования данных, и они написали о том, что она может сильно пригодиться тем, у кого нет нормальной СУБД (не дословно, но смысл примерно такой). Я это к тому, что Enterprise проекты (которые очень любят ORM) обычно крутятся на серьезных СУБД, например, Oracle. Я не специалист по СУБД, и ничего не рекламирую, но с Oracle я не включаю даже базовых функций кеширования, встроенных в Hibernate потому, что уверен на 100% в том, что Oracle гораздо лучше знает что и как кешировать.
По поводу ваших проблем с джойнами и прочими сложными запросами: лично я никогда не формирую сложные запросы на языке ORM (в моем случае Hibernate-овский HQL). В Hibernate отличная поддержка native query: можно отдать Hibernate-у чистый SQL, а получить в ответ замапленные сущности (т.е., те же, что вернул бы HQL).
Насчет Вашего последнего абзаца — очень, очень спорное заявление. То, что "в состоянии написать любой java-программист", должен будет когда-то поддерживать и дорабатывать другой java-программист, и с почти 100% уверенностью можно сказать, что проклятий в сторону первого будет немало. ORM, кроме непосредственно технологий, являются еще и неким подмножеством языка, знакомым большинству программистов в отрасли. Когда приходит новый человек на проект и видит Hibernate, у него вряд ли возникнет вопрос «зачем это здесь», а вот если он видит очередной велосипед… Опять же, на личном опыте: 10 лет назад, когда я был совсем джуниор, старший программист решил внедрить ORM в один из общих модулей проекта. Я тогда разве что головой об стол не бился, пытаясь понять какой велосипедист придумал Hibernate, а потом проникся. Я сейчас даже в микропроектах его использую, очень удобно…
Я считаю, что автор статьи абсолютно неправ, связывая незнание SQL/принципов работы СУБД и какой-либо конкретный язык программирования (а переводчик неправ, защищая его точку зрения).
Мне не раз встречались, например, системные администраторы, не имеющие никакого отношения к программированию, которые одним простым запросом давали нагрузку на базу в тысячи раз большую, чем любой запрос, отправляемый из ПО. Любимая ошибка многих — в условии ограничения выборки взять в кавычки значение, накладываемое на числовое поле (или наоборот). Результат: мало того, что индексы не работают, так еще и выполняется конвертация значений поля во всех записях таблицы.
Похожая ошибка у программистов — при накладывании ограничений по дате применять функцию приведения значения не к передаваемому условию, а к полю в БД: вместо "to_date(моё_значение) = поле_таблицы" делать "моё_значение = to_чтонибудь(поле_таблицы)".