ORM как раз и предназначен для инкапсуляции бизнес логики, но не на уровне СУБД, а на уровне приложения.

Использовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.

SmeL_mdрубистИспользовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.
Как то все натянуто за уши. Нужна скорость пишите хранимки. И все эти минусы из пальца высосаны.
И про ORM тоже самое, нужна скорость отказываемся и от него.

"Нужна скорость пишите хранимки" - как-то натянуто за уши и высасано из пальца :) ....

Единственное где оправдано использование хранимок это отчеты или обработка древовидных структур данных,при условии, что этих хранимок не много или у вас есть кому ими заниматься.
В остальном, скорости обычно не хватает если выбрано неудачное алгоритмическое решение или само приложение написано не качественно.
Компенсировать недостатки приложение написанием хранимок это не выход.
Мне доводилось работать с системой у которой вся бизнес логика была на хранимках ....
больше сотни таблиц и еще больше хранимок. В конторе был целый отдел, который знаимался только хранимками (T-SQL). жесть.

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

Начинающий ORM-щикрубист,

наверное спорный вопрос где лучше расположить бизнес логику в t-sql или в orm.
Просто вместо отдела t-sql был бы отдел php программистов :)

Отдел программистов тоже был, как ни странно :),
но ты прав вопрос не просто и зависит от многих факторов.

SmeL_md,

При чем здесь количество хранимок, при чем здесь штат
При том, что львиная доля расходов на проект это этап "эксплуатации\сопровождения"
Если бы 1С-шники зарулили логику в хранимки, то давно бы обонкротились.

или потому что не пользуетесь хранимками т.к. нет специалиста по БД, а так как его нет вот и не справляются запросы после того как системой годик второй .....
Я написал уже, хранимками нужно пользоватся только по делу, если действительно нет другого решения.
Но лучше старатся их избегать. Это мое ИМХО, сложившееся годами. Ни кому не навязываю.

И что тут плохого :) вы тут про безопасность поразмышляйте про целосность
Безопасность и целостность ни как не зависят от использования или не использования хранимок.
Это зависит только от прямоты рук.

Кэширование :) разделение прав уж точно дела не ORM а СУБД.
Про миграцию через ORM DBA вам бы точно руки по отрывал:)
Да, СУБД кеширует запросы, но на уровне ORM тоже есть возможность кеширования.
Разделение прав это дело приложения и ORM очень в этом помогает.
Здесь я имею ввиду не права доступа в саму СУБД, а права доступа пользователей на уровне приложения.
имхо: СУБД, по бальшому счету, должна отвечать только за получение\хранение\отдачу данных.

Мне вот интересно, как вы собираетесь обходить те минусы о которых я писал выше, при создании бизнес логики на основе хранимок?
Я их специально упомянул, так как по ним почти нет готовых решений. Наколенные велосипеды не предлагать :)

ShSergeНачинающий ORM-щикКто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?...
Угу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
По моем автор вообще php не упамянал.
При чем тут всякие делфи и сишарпы?, речь об использовании ORM в принципе.

Походу вы нормальный ORM в глаза не видели и не работали с ним в реальном проекте.
.... типа "не читал, но осуждаю" :)