Зачем работать с базой ORACLE только через процедуры?

Question

[Сергей]

Я вот работаю с PHP + MySql, и с базой я общаюсь запросами типа SELECT, UPDATE, INSERT.
Мне говорят что - а мы работаем с PHP + ORACLE, и программисты PHP работают с базой только через процедуры.
Я так понимаю что есть разработчик ORACLE который пишет эти процедуры, а PHP программисты просто их вызывают с нужными параметрами?
Я правильно понимаю? Если да, то зачем такой подход? И правильно ли это?

Answer 1

[Sumor]

Если проект простой, то конечно удобнее из клиентского приложения вызывать SELECT, UPDATE и INSERT.
Но как только проект становится достаточно большим, или накладываются дополнительные ограничения на безопасность, то удобнее вынести часть бизнес-логики на сервер. В данном случае - на хранимые процедуры.
Плюсы следующие:
1. Хранимые процедуры и клиентское приложения могут писать разные люди (команды), с разной подготовкой. Хранимые процедуры - боле опытные, клиентское приложение - более неопытные.
2. Хранимые процедуры могут обеспечить дополнительный уровень безопасности. Часть проверочной логики может быть реализовано на сервере. И клиентское ПО даже изменив или подделав вызовы не получит не принадлежащие им данные. Если вся логика приложения реализована на клиенте, то злоумышленник может переписать запросы и получить не принадлежащие ему данные. Помимо этого от клиентского ПО скрывается структура БД.
3. Хранимые процедуры, как неинтерактивные модули, проще отлаживать и тестировать в автоматическом режиме.
4. Написанные хранимки меньше, чем клиентское ПО, подвержены изменениям в ходе эволюции и активно повторно используются в разных клиентских модулях.

Answer 2

[res2001]

Нормальный подход. 20 лет назад он был фактически стандартом.
Разработчик баз данных обычно стоит дороже PHP разработчика.
Сейчас, обычно, такой подход используют в корпоративных разработках, где могут позволить держать таких специалистов.
А в mysql еще совсем недавно не было никаких хранимых процедур. С тех пор так и пошла мода всю логику запихивать в сервер-приложений.
Это ни плохо и не хорошо, нужно идти от задачи и знать сильные и слабые стороны размещения бизнес-логики в сервер-приложений или в сервер базы данных.
https://habrahabr.ru/post/219445/

Answer 3

[d-stream]

Простейшая ситуация: update нескольких таблиц по результатам отбор из других .
Отдельные запросы "извне" рискуют не выполнится (например обрыв связи). Инициации транзакций в такой схеме - чревата при том же обрыве связи их незавершением.

А процедура - можно считать ее неотъемлемой частью БД - гораздо меньше подвержена всему этому. Ну и как бы "атомарна" в рамках реализации бизнес-логики.

Изменения структуры данных в данном случае могут затронуть лишь бд-сторону (структура таблиц и процедуры).

Answer 4

[Евгений Быков]

У меня был опыт участия в написании системы OLTP, в которой был достаточно высокий темп апдейтов, причем часто апдейтились одни и те же записи (из разных транзакций). Для того, чтобы избежать задержек, нужно было обеспечить быстрое завершение транзакций (явный commit или rollback). Если клиент обращается к БД не через хранимые процедуры, то управление транзакциями выполняется на стороне клиента, а значит, если клиент поведет себя некорректно (не станет быстро завершать транзакцию), или возникнут проблемы со связью в середине транзакции, то записи, которые апдейтят многие транзакции, окажутся заблокированы этой подвисшей транзакцией. Если же клиент взаимодействует через хранимые процедуры, то управление транзакциями осуществляется из таких процедур (явно начинается и явно завершается в одной и той же процедуре). Это минимизирует время транзакции. Для нас это было одной из основных причин применения хранимых процедур. Хотя, конечно, существенно было и то, что минимизировался трафик между клиентом и БД. На мой взгляд, эти две причины имеют достаточно большое значение именно для OLTP.
В другом проекте (на MS SQL) были огромные объемы исходных данных. Для сокращения размера БД было разработано очень специфическое представление данных в таблицах, так что эффективно можно было выполнять только некоторые предопределенные запросы с обязательными параметрами. Если в этих запросах не задать обязательные параметры и/или добавить дополнительные условия, то оптимизатор мог запросто выбрать план выполнения, при котором сервер "уходил в себя" (результата дождаться было просто невозможно). Однако заказчик требовал обеспечить ему доступ к этим данным (например предоставить некие views) из его приложений. Если бы мы предоставили ему views, то при использовании их он мог бы не задать обязательные параметры, задать дополнительные условия, перевязать эти view с какими-то другими таблицами/views/подзапросами. При выполнении таких запросов запросто возникли бы проблемы с производительностью (причем, всего сервера БД). Мы передали заказчику набор хранимых процедур с обязательными параметрами (не задать их он уже не смог бы), возвращающие резалтсеты, которые он может вычитывать точно так же, как при выполнении обычного запроса.

Answer 5

[Barmunk]

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

Answer 6

[Yo!]

основная причина - пхп это не типизированный язык, тяжелую бизнес логику на таком писать моветон. оракловый pl/sql типизированный язык, глубоко интегрирован с данными. в пхп ты обновил код и только можешь помолиться, что код пхп ожидает те самые данные, что в базе. если кто-то удалил таблицу, пхп код об этом ничего не знает. процедуры в оракле знают к каким таблицам обращаются, знают какие типы колонок. т.е. если ты накатил на базу кривой патч, сразу это видно, затронутые процедуры станут инвалидными и оракл не позволит целиком запустить кривую процедуру. пхп код же пока не наткнется на косяк, не будет подозревать о засаде.
плюс тяжелую бизнес логику на pl/sql проще писать, т.к. можно привязаться к типу таблицы объявляя table1.name%type, table1%rowtype. плюс можно писать гораздо более эффективный код, оперируя данными конструкциями типа bulk collect, bulk insert.

Answer 7

[Артемио Вегас]

Сам знаю примеры банков где так поступают, интерфейс на пхп, а бизнес логика - процедуры Оракл, и не всегда процедуры Оракл пишет отделный программист (ну тут уже от квалификации зависит), ну и плюс сложную логику для работы с БД проще в процедурах делать