Недостатки хранимых процедур

Здравствуйте.
В рамках курсовой работы разрабатываем модель провайдерской системы.
Для того, чтобы у пользователей списывались деньги каждый месяц мы написали event, который запускает хранимую процедуру, которая списывает деньги со счета.
Препод сказал, что это фигня и нужно писать отдельный скрипт, который будет этим заниматься.
Скажите, почему использование хранимых процедур в данной системе плохо?

у препода и спроси - откуда тут знают что там за системма

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

В смысле что за система?
Это база данных mySQL. Препод сказал, что хранимая процедура это плохо для подобного случая.

А чем плох Php? Чем плох JS? Все зависит от Вас.
А так первое что приходит в голову, проблемы с расширяемостью. Хотя х.з.
"Нужно забить гвоздь, возьми молоток и забей".
Плюсы тоже есть. Все решать Вам.

а ты сначала ответь почему именно хранимка?
нафига?
минусы
плохо читается
отсюда поддерживается плохо
хз как расширяяемо
а если сервер бд сменить придется
а тесты писать
хотя надеюсь придут более опытные и самому интересно
сам интуитивно обхожу стороной хранимки и тригеры
только раз триггеры применил но там я точно знал зачем
(Добавление)
а если надо будет добааить условия которые невозможно учесть в бд?
а если например перенесете данные в единое хранилище для мнногих приложений?
и каждое из приложений будет накладывать свои ограничения
короче поддержка хромает
наерное

получаеться холивар CRON+PHP vs EVENT + PROCEDURE.
как по мне если функционал меняться будет редко то второй вариант подходит не чем не хуже чем первый.

П.С. не раз использовали тригеры и процедуры. если их правильно готовить то ничего страшного не происходит.
и также вопрос

Сколько раз за вашу практику менялся сервер БД? за мою ниразу. а если еще учесть что всеравно большинство запросов в том же ПХП пишутсья под конкретную БД, то тем более уверен что никогда

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

Поетому написал выше что оправдано если если функционал меняться будет редко

(Отредактировано автором: 10 Июня, 2014 - 11:39:30)

1 раз с mysql на redis значительная часть переехала
но это как бы 1 из многих "если"
лично для хватит только того что надо увидеть запрос хранимки и лезть ее смотреть и это при отсутствии всякой видимой выгоды

типа "просто я знаю что это можно делать и потому сделал"
(Добавление)
ну в этом случае вообще можно забыть про всякую архитектуру и писать plain код )))

TL;DR

Если вы не знаете, нужны ли вам хранимые функции/процедуры, то они вам не нужны.

Use-cases

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

Кроме того, иногда бывает нужно реализовать вещи которые попросту отсутствуют в СУБД. Для MySQL это - например, замена по регулярному выражению. Не так давно я реализовал это. Конечно, есть UDF - но далеко не всегда возможно их использовать (равно как и устанавливать сторонние библиотеки)

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

1. Бизнес-логика размазывается по 2 системам - часть кода у вас на php (обращение к внешним системам, валидации, обработки ошибок, логи и тд), часть в хранимых процедурах (списание, смена статусов - все, что внутри транзакции)
2. Если вам придется шардировать данные, как на хранимых процедурах вы организуете работу с несколькими удаленными серверами?
3. Сложно организовать детальное логирование происходящего в системе, обработку разных типов ошибок. А вы работаете с деньгами, все ходы должны быть записаны
4. Вы не сможете некритичные данные получать с ro-реплик, разгружая rw-базу.

Наверняка, есть еще, но это что первое в голову сразу приходит