Стоит ли изучать sql, или же сразу заняться изучением ORM?
Все люди которые ратуют за использование ORM с годами все равно приходят к очень сильной
и мотивированной необходимости знать SQL. Этот язык сегодня является латынью баз данных.
Вы сможете говорить с бизнесом на одном языке если будете в переписке активно использовать
например язык DDL таблиц. Ваши аргументы будут выглядеть убедительно если в переписке будут
фрагменты например любой консоли MySQL, psql, SQL*Plus e.t.c. Короче знание SQL - это признак
джентльмена. Путь в приличное общество.
И наоборот, вы будете вообще НЕПОНЯТЫ если попробуете показать ORM объект на Node или не дай
бох на Java/JPA техниках аннотации. Бизнесу эти аннотации неинтересны и неинформативны.
Да и вам самомму смоделировать любой сложности выборку или отчет будет бытрее в SQL чем в фрейморках
ООП-отображения.
Что касаемо перформанса. К сожалению все современные ORM реализуют только самые базовые возможности
оптимизации запросов. Насколько я знаю Hibernate (по состоянию на 2015 год) так и не умел обращаться
с Oracle Hints. А любой сложный ентерпрайз начинается там где вы выжимаете из запроса не 100 а 1000%
возможностей. И здесь вам нужно управлять проприетарными функциями воздействия на оптимизатор.
Вообще для меня например цикл оптимизации ORM запросов начинается с того что я выбрасываю из
стека ORM. Заменяю на native. И долго наблюдаю его и оптимизирую. И когда достиг критерия готовности
то пытаюсь затащить обратно в ORM. Иногда не заходит. Это те случаи когда ORM оказался плох.
Эти случаи сложны, синьорны. и по каждому из них можно здесь в хабре открывать статью как минимум.
Но не все так плохо. Существует взгляд на ORM с обратной стороны. Это фреймворки наподобие MyBatis.
Они в первую очередь решают проблемы БД а уж потом дают опции объектных возможностей. Короче
Батис - это ОРМ наоборот. Где эволюция системы идет не от кода к БД (как любят хипстеры) а от
имеющихся вызовов процедур
и запросов к объектам респонса.
Простой
