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

К сути. Руководитель в текущем проекте настаивает на полной инкапсуляции всей логики работы с БД в хранимые процедуры MySQL. Меня, как разработчика, такая идея очень удивила. Я уже давно свыкся с мыслью, что ведущие разработчики всего мира являются приверженцами объектно-ориентированного подхода к программированию. Благодаря этому движению мы имеем паттерна ActiveRecord и проекторы, вроде Doctrine, которые по сути призваны реляционную логику приводить к объектно ориентированной. На фоне этого использование хранимых процедур мне кажется возвратом в каменный век. Т.е. имхо с точки зрения удобства в работе - это просто катастрофа.

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

Так вот у меня вопрос. Какой смысл от этого подхода?

В чем?
После взлома сайта могут залить тот же пыхадмин и получить данные из СУБД, в том числе и хранимые процедуры (а из них вывести опять все связи).

MoLeX, Предполагается, что приложение не может выполнять произвольные запросы - только процедуры. 

Кто ограничивает приложение? Внутренняя самодисциплина разработчиков? Или есть более другие способы запретить выполнение любого запроса?

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

Добавлено через 4 минуты и 48 секунд
Просьба не уходить от основной темы топика - хранимых процедур. Вопрос безопасности - это частность, а меня интересует ваше общие мнение о данной технологии.

правила форума запрещают использовать всю мощь русского языка, если вкратце: да ну её нафиг

Смысл в отделении логики приложения от различных фронтендов.

php и web-интерфейс это не единственные потребители БД.

А если единственные?

Весь проект самодельный и переписывать - добивать его будет одна и та же команда разработчиков? 

Следует понимать, что ни один сторонний модуль подключить не удастся. 

Придется самим писать все служебные утилиты навроде phpmyadmin. Ну или запускать такие утилиты под более правильным аккаунтом.

Это сообщение отредактировал(а) ksnk - 6.6.2012, 16:53

Я думаю этот вопрос стоит задать руководителю ...

А без "если".

Оценочный размер проекта в человеко-часах.
Круг задач, которые он должен решить.
Доступные ресурсы


Этот тот минимум, чтобы можно было хотя бы гадать на кофейной гуще.

Добавлено через 1 минуту и 13 секунд

Это о чем?
Какой сторонний модуль?


Разве это проблема?

Хранимые процедуры лучше использовать в триггерах когда происходят какие то события с таблицами но не более, переносить логику в БД это тупость.

Fortop, 
Кратко.

Проект рассчитан на 2 месяца, задача/цель - каталог с возможность заказа (без оплаты) со сложным механизмом фильтров и выгрузкой данных в CRM, ресурсы в разумных пределах не ограниченные.

Архитектура проекта целостная и предполагает только выгрузку данных по собственной инициативе. Т.е. единственный потребитель базы данных - само приложение, оно же и занимается выгрузкой данных. 

Не каких сторонних потрибителей, согласно спецификации, в проекте не придусмотренно.


Руководитель ответил, что так мы избавляемся от необходимости писать SQL в коде и улучшаем безопасность. Более подробных комментариев получить не удалось.


Не знаю, что именно имел ввиду ksnk, но меня ооочень сильно напрягает невозможность работать с базой через ORM.

Это сообщение отредактировал(а) BuShaRt - 6.6.2012, 23:49

Систему комментариев на сайте, почтовые рассылки, служба online-саппорта и так далее - все это придется не брать готовыми из готовых проектов а писать самим практически с нуля... 
Если сверхзадача - написать все самим и самим же это все тащить, развивать и поддерживать, то почему бы и нет, но скорее всего задача - получить работоспособный, расширяемый проект 

Это сообщение отредактировал(а) ksnk - 7.6.2012, 00:18

Таких модулей в проекте не придусмотренно =) Все сами... ну или за счет более мелких составляющих..