Почему и когда стоит использовать ханимые процедуры в MySQL

Данный топик навеян и тем фактом что автор разместил его в разделе «Ненормальное программирование». Печально это видеть, честное слово. И вот

Во первых — ХП это безопасность

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

Кроме того, многие забывают (или не знают, или считают что это невозможно...) что во многих проектах данные должны защищаться не только от взлома извне, но и от программистов пишущих скрипты. Особенно и в квадрате это необходимо при использовании на проекте фриланс-работников. Если мне нужно подправить пару тегов на страничке каталога товаров — это ведь еще не повод давать фрилансеру доступ к базе клиентов магазина, нет?

Еще один аспект безопасности про который тоже часто забывают — это безопасность данных от случайного повреждения, гм простите за прямоту, криворукими программистами. Проблема в том, что от кривого кода который вместе с добавлением новой заявки перепортит вам еще и пачку старых (UPDATE без указания id — и привет) не поможет обычный бэкап. Потому что во первых — многие вещи «вылазят» не сразу, а во вторых — в бэке у вас будут целые старые данные а в текущей базе — целые новые — но битые старые. А склеивать придется ручками…

Ограничить полет фантазии человека нанятого написать какую-то отдельную часть сайта и сделать так, чтобы он не смог ничего нигде поломать при «стандартном» подходе (запросы в теле скриптов — пусть даже и в отдельных модулях) почти невозможно.

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

Во вторых — ХП это возможность прозрачно и невидимо для не-ведущих программистов работать с несколькими базами в пределах сервера

Это неочевидный (но вполне стандартный) функционал (FROM nhpublic.`метро`) дающий еще очки в копилку безопасности и надежности проекта.

То, что Ваша процедура журналирования делает записи не только (а может и вообще — только НЕ) в вашу «основную» базу будет знать только ведущий программист, который ее и написал… Еще лучше было-бы работать с базами и за пределами основного сервера — но увы, тут MySQL имеет слишком много проблем (зато под M$ это работает отлично)

Где это нужно и хорошо? Вот если у Вас есть группа взаимосвязанных проектов на одном сервере — то довольно удобно использовать одну) общую базу КЛАДР а не стопицот ее копий. Тоже самое и с общей авторизацией. У Вас может быть одна общая база авторизации — а обращения к ней будут транслироваться через ХП.

В третьих — возможность использовать различные клиентские приложения

Тут даже описывать нечего… Вы просто пишите GUI приложение на Delphi/Java/VS (любимое подчеркнуть/добавить) и используете нативные методы для вызова ХП. Все. Вам Не нужно больше делать копии запросов и обеспечивать их синхронность/идентичность. А Ваш босс при этом имеет гораздо более функциональное приложение для просмотра отчетов своего магазина.

АПИ

Да. Используя ХП вы фактически создаете полноценный АПИ для Вашего проекта. Да, это требует напряжения мозга для ведущего программиста. Зато позволяет спокойно использовать куда менее квалифицированные кадры для написания бОльшей части скриптов интерфейса. Вы просто даете разработчику УИ заголовок процедуры:

`БиллингБаланс`(
 $КлючСессии NVARCHAR(32)
 , $КодПользователь INT(11)
 /*
 Возвращает баланс указанного пользователя.
 При этом простой пользователь может видеть только свой баланс,
 а админы - баланс любого пользователя.
 ---------------------------------------
 28.07.2010 - Fox - Первоначальная версия
 */
 )

и если он неполный пень — то все будет работать так, как Вы запланировали.
Да! Я использую Русский язык в коде!
И это отлично работает. Потому что за файлы отличные от UTF-8 я выдергиваю руки сразу. А в остальном — это сильно экономит время. Не надо убеждать меня в том, что все cразу поймут что за receipt имелся ввиду. А то, что на переключение раскладки требуется время — так это даже хорошо — лишняя пара секунд подумать — прежде чем что-то писать, никому еще не вредила. Скорее наоборот.

Код в одном месте

Опять же — это свойство наиболее мощно проявляется при наличии группы проектов использующих общие базы. Попробуйте «расшарить» один PHP скрипт для работы с БД (Model) между несколькими доменами (запущенными пусть и на одном сервере — но под разными пользователями) и вы поймете, о чем я. А иметь несколько копий одного скрипта — отличный способ по увеличению количества седых волос.

Наверное, я перечислил наиболее важные (имхо) моменты. Есть еще дьявольски большое количество приятных мелочей. Но думаю пора сказать и о грустном. Точнее — о тех вещах, которые многим мешают воспользоваться все мощью ХП.

Отвратительная поддержка работы с ХП из ПХП

Без комментариев. Для того чтобы начать нормально работать вам придется выкурить много манов. Но не все так плохо — настроив все один раз (модуль 115 строк в моих проектах) вы забудете об этой проблеме.

А как их создавать, админить и вообще?...

Просто надо знать прикуп. Есть отличные среды разработки для MySQL в том числе полностью Русские (не перевод! Есть нативно Русский проект). Не буду писать тут название.

Вы знаете еще минусы? Комменты для Вас

А, я больше минусов просто не назову.
Вся ерунда про быстродействие и прочее — это ерунда. Правильно написанная ХП уделает любой код на ПХП на сто рядов. А если вы не можете написать нужный код в ХП, вам нужны циклы по 10к итераций, или что-то еще — значит вы просто пытаетесь засунуть в model то, что model не является.

Так что в большинстве случаев, когда мне говорят, что ХП на MySQL это плохо — ответ простой «Ты просто не умеешь их готовить». А вот о том как</> их готовить — наверное уже в другой раз. Ибо тема эта слишком велика для одного поста.