Забегу вперед и сразу отвечу на вопрос, почему этот топик я создал в этой ветке. Суть вопрос не в технической реализации хранимых процедур, а в том, как это отражается на архитектуре приложения, которая прежде по большей части строилась на базе 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

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

Это точно система online-заказов?   

И каким образом это связано с проектом и его базовой логикой?
Отдельные подсистемы поддержки, интеграция в проектом не будет слишком уж сложной.



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

В остальном... смысл небольшой есть, если у вас есть хороший DBA.
Если все пишет один человек - смысла 0.

C базовой логикой - никак не связано, а вот с потребностями по расширению проекта, которые придут в голову сразу после успешного запуска - связаны. 


посмотри на ulmart - как бы тоже каталог, без оплаты, со сложным механизмом фильтров.   

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

100%

Жёсткая привязка к типу БД, да и к свойствам таблиц и их полям.

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

Я бы порекомендовал бы всё равно вызов процедур вынести в отдельный класс шлюза к БД на той же платформе что и само приложение.
Это бы дало лучшую гибкость вслучае, если всё таки проект будет расширяться, так как в методах такого класа можно без труда изменить логику доступа к БД, не затрагивая клиентского кода. (впринципе может Вы так и сделали ) 

Это сообщение отредактировал(а) Sentox - 7.6.2012, 22:59

Это не имеет значения для продукта внутреннего пользования



И где там сложная логика работы с БД

Идиотский и перегруженный интерфейс вижу. Но и не более того

Это просто пример развития "каталога без оплаты". А сложность и в facebook'е нету. Все просто