sti Вопрос в том, есть ли какие-то стандартные способы реализации?

DSL. Или вы ждёте какой-то магии и волшебства?

tunknownЕсли база на SQL, то за DSL можно взять сам SQL.

Это практически заживо себя похоронить.


tunknownОтдельный вопрос- правильно это или нет, но такая практика часта даже в коробочных продуктах.

Это по инерции. Повсеместно от логики в SQL отказываются и выпиливают при первой же возможности. Остаются лишь существующие системы на поддержке. И старперы, которые не смогли прыгнуть дальше хранимых процедур в силу ограниченности и неспособности мышления, которые продолжают пихать их разработках. Кушать всем хочется.

tunknownПотом приходится поддерживать новомодные студенческие поделки, т.к. сами "студенты" этого не могут осилить. Но этот разговор не по текущей теме.

Я не понимаю. Если вы говорите о студентах, подразумеваете ли вы, что те же студенты, которые делают "поделки", вдруг пишут качественные хранимки? Не находите, что ваше странное заявление -- абсурд.

При чём, по моему опыту и моей памяти, хранимщики до старости лет остаются на уровне студентов и пишут в хранимках такое адище, что даже нашим джунам плакать захочется. Связано это с тем, что хранимщики обычно плевать хотели на принципы и паттерны разработки, это ещё очень хорошо, что они вообще про это знают или хотя бы слышали.

tunknownВаше мнение по ORM я понимаю, но не разделяю.

ORM тут не при чём. Я говорил в начале про DSL, люди должны писать логику в терминах бизнеса, а не в терминах реляционной модели.

alex55555в ситуациях, когда надо спрашивать "как понравиться заказчику больше"

Имхо, подход «понравиться заказчику» это тупиковый путь :) Нужно не понравиться заказчику, а решать его задачи, чтобы заказчик поимел с этого выгоду, и желательно не разовую, а с перспективой.


alex55555"как в такой-то тулзе запустить заявленную в её рекламе возможность?"

Фиче-ориентированный подход. Знаем, проходили :) Тоже не айс. Одна действительно нужная и правильно реализованная фича дороже и выгодней десятков прикольных, но никому не нужных.

tunknownВопрос не в качестве работы, а в том, что хранимые процедуры хотя бы можно отдельно пооптимизировать в отличие от парадигмы- "у нас технические ограничения ORM". ORM- это вкомпилённый монолит, наличие же SQL позволяет говорить о слоях доступа.

Вопрос в качестве работы. По-оптимизировать запрос тоже можно, и без всяких хранимок. Клиенты с СУБД по-вашему на каком языке общаются? На птичьем? Какое отношение оптимизация имеет к хранимкам, интересно? Да и зачем заниматься этой обезьяней работой.


tunknownЛибо они применяют методы, не знакомые смотрящим со стороны ORM.

У вас пунктик по поводу ORM. Я бы мог бы с вами и здесь поспорить, но я вообще не говорю про ORM. Я топлю за то, чтобы не заниматься обезьяней работой. Не писать SQL, если это может сделать машина. И про оптимизацию это тоже касается. Просто не все умеют, и приходится обезьянить в хранимках. Тут уж у кого на что хватает тямы.


tunknownIF/CASE/WHILE/SET и прочее относятся к общим предложениям процедурного языка, а не к реляционной модели. Если DSL процедурный, то это делу не мешает. Если нужен декларативный DSL, то этот метод не подходит.

Вы забываете, что кроме непосредственной работы с данными, которые к слову сказать могут лежать где угодно, не только в одной единственной SQL СУБД, но ещё и в кеше, в ElasticSearch, разбросаны по кластеру, по микросервисам, и вообще по разным подсистемам, в программном комплексе. Куда тут можно воткнуть жалкие несчастные хранимки, я даже не знаю. А как обеспечивать безопасность, не грантованную, а именно пользовательскую. Везде в хранимках вставлять WHERE и потом героически поддерживать? Да это примерно как плюнуть в лице работодателю и сказать, я не умею и не хочу учиться делать по-нормальному, буду делать как умею, по-обезьяньему, платите деньги и не жужжите