KimelЯ занимаюсь разработкой небольшой erp под определенные нужды (не убийца 1С).
Разработчик я не очень опытный поэтому хотел бы поинтересоваться у профессионалов:
Стоит ли переносить большую часть логики связанной с БД в хранимые процедуры или лучше это обрабатывать в модели приложения?
Бизнес логика состоит как из простых CRUD запросов, так и из сложных запросов, которые затрагивают одновременно большое количество таблиц.

Как себе я представляю архитектуру:
простые CRUD запросы хранятся в модели, ими занимается orm, так как это очень просто.
сложные запросы в хранимых процедурах БД, которые orm будет вызывать.

Возможно я что-то забыл упомянуть, надеюсь вы меня поправите.

РМД это сильно ограниченная модель. Поэтому были "придуманы" процедурные расширения (например TSQL, plsql), чтобы обойти ее ограничения.
Выбирая перенос логики в БД вы привязываетесь к вендору СУБД.
"Промежуточные" варианты не живучи, т.к. нужны специалисты которые хорошо знают и ЯП, и язык ХП конкретной СУБД.
В конце, концов "остаться должен только один" и обычно это программист БД.
Так что если остановитесь на БЛ в ХП, то сразу пишите REST-сервисы в БД.

Лично я бы рекомендовал в СУБД хранить только данные.
Причем без всяких ХП. Только голый SQL.

А всю БЛ писать на удобном для вас ЯП.

ORM так же бы не рекомендовал использовать (Точнее не пытатся ч\з ORM хранить объекты).
Все равно придется писать слой, который будет перекладывать сущности в необходимые объекты.
А хранение объектов в БД, приведет к тому, что придется писать ХП.
И БЛ "размажется" м/у сервером приложений и БД.
Что плохо скажется на сопровождаемости проекта.

P.S. А так, решайте сами. Вы должны сами наступить на все грабли, чтобы понять, какие грабли для вас предпочтительнее. :-)

Kimelcaballero,
mad_nazgul,

Я так понимаю, если я буду всю бд логику хранить в модели (включая взаимоотношения таблиц все эти каскадные удаления и прочее), то я всё равно столкнусь с тем, что допустим у меня уже сейчас в хранимой процедуре лежит запрос на 100 строк и не какой-то монстр в виде 50 джоинов, нет, нормальный запрос простые он с нарастающим итогом и другими плюшками.


Для чего этот запрос?
В обычном CRUD приложении это не нужно.
Это либо нужно для "отчетов", либо для "аналитки".
В первом случае лучше использовать построитель отчетов (для меня JasperReports).
Во втором случае использовать OLAP (для меня Mordrian)

KimelЯ реализовал его с помощью процедурного языка (то есть сделал несколько элементарных селектов, а все остальные операции делала уже другая программа) и в виде запроса SQL и когда сравнил скорость выполнения то всё стало на свои места. Оптимизатор запросов в субд решает!


Если можно получить данные из SQL запроса, то лучше получить данные из SQL-запроса.
Опять же повторю ХП-это костыль, т.к. РМД очень ограниченная модель.
Можно использовать этот костыль, когда это оправдано.
Но его использование лишает смысла "слоя-приложения".
Т.е. проще будет сделать клиента (отображение), который будет напрямую работать с БД ч/з ХП.
Так можно. Почему бы и нет.
Но для меня не очень удобно.

KimelИ выходит, что даже если я буду подобные запросы хранить в модели в виде raw sql, то я всё равно получаю привязку к вендорам, так как нужно этот raw sql писать под каждую базу.


Зачем?
Все современные SQL-БД как минимум поддерживают SQL-99.
Более новые "фичи" надо смотреть по реализации.

KimelМне не понятно, как и где хранить сложные запросы?

Еще раз "сложные" запросы зависят от задачи.
Обычно "сложные" запросы возникают либо, для "отчетов", либо для "аналитики".
Для них есть специальные инструменты и фреймворки.

P.S. Сделать свою "OLAP на коленке" можно, но не нужно, т.к. они уже сделаны :-)