Я уже несколько лет как прокачивают навыки дба, оставаясь при этом и разработчиком. Да вакансий дба меньше, ну а рынок толковых спецов по бд ещё меньше, на порядок! Ну а по рынку фриланса, в том числе зарубежного, особенно на фоне популярности всяких там три, я понял, что работы для дба непочатый край. Надо же кому-то потом исправлять то, что наговнокодили разрабы, особенно фанаты орм. :)
Кстати, по фрилансу много заказов от самих разработчиков. А то с течением времени их говноподелка почему-то стала дико тормозить. Докупили железа, но это помогло ненадолго, а потом и вовсе перестало помогать. Вот тогда-то они и приходят к дба. :)
Так что фанаты тем - это благо для дба, без работы не останемся))

Вам что, ссылку на таск на бирже фриланса или описать словами? :)

Если словами, то, различные crm\erp-системы, где более-менее сложная логика, аналитика. Один заказ был, разработчик написал ПО под MS SQL на каком-то entity фреймворке. С увеличением размеров данных, как я понимаю, все стало дико тормозить. Клиент сам увидел, во что превратилась его система и решил переписывать без entity, логику переводить на сервер, в хп. Ко мне обратились как к специалисту по БД.

Другой вариант. У одной украино-американской конторы есть ПО на ОРМ, только какой-то по ходу свой движок. Какие-то запросы они все же сами пишут. Куча клиентов по всему миру. ПО умеет работать с MS SQL и с PostgreSQL. Сильно заковыристых запросов у них нет. Большую часть логики реализовывают на клиенте. Но вот загрузка данных в систему(порядка 50млн. записей), с каким-то расчетами занимает больше 2ч на MS SQL. Ну типа их заказчиков это устраивает... Хотя, думаю, с логикой на сервере там можно было бы все за полчаса, максимум, загрузить, с расчетами, а то и быстрее.
С MS SQL у них все просто: добавили памяти, работает на столько-то шустрее. С PostgreSQL так не получается, надо настраивать.
Вот они ко мне обратились насчет донастройки PostgreSQL.

p.s. я не говорю, что ОРМ - это однозначное зло. Для автоматизации простых задач без сложной логики их можно использовать, или для автоматизации простых линейных операций в сложном ПО. А для задач, где сложная логика, таки придется уметь писать качественные запросы и уметь их оптимизировать.

Я вас не понял. Вы вроде просили примеры говноподелок фанатов орм, а не примеры говнокода, который генерит орм.

Насчет генерации говнокода ОРМом. Вот в этой статье пишется про "фирменный" почерк Django.

Планы будут одинаковыми может быть в 80% случаев, но остальные 20 вам сделают проблем намного больше.

Кстати, в чем заключается лучшая поддерживаемость кода на клиенте? Только в том, что на фирме нет людей, хорошо знающих SQL, но знающих код клиента?

p.s. тысяча хранимок - это плохо, если можно обойтись 100, но должным образом параметризированных. Но если функциональность разная, то какая разница, сколько хранимок? Вы же не предъявляете претензии к объему клиентского кода... Ну может и так. :)

Можно пример функционала, когда на сервере тысяча хранимок(для чего?), а на клиенте 1 метод? Мне просто сложно это представить... Обычно 1 метод на клиенте равен 1 хп на сервере.
Кто вам мешает все вызовы в БД завернуть в один метод верхнего уровня, как вы сделали с клиентским кодом?

Не, есть бизнес-логика, которую на клиенте бывает проще обработать, но в целом это редкость. Да и СУБД развивается. Используя же СУБД посредством ОРМ, вы лишаетесь множества полезного функционала.

Часто ОРМщики, да и не только они, работают с большими объемами данных построчно, например, для заливки данных в БД. Тогда как это можно сделать на sql одной командой. Скорость работы на порядок\два будет выше.