Что лучше триггер или процедура? И почему не запихнуть бы всю логику в процедуры?

Question

[ddddd tttt]

Что лучше триггер или процедура? И почему не запихнуть бы всю логику в процедуры?

Answer 1

[Константин Цветков]

Что лучше триггер или процедура?

В процедуру не передаются таблицы inserted и deleted, они требуют явного вызова. А в триггерах запрещены некоторые операции.

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

Можно, некоторые так и делают: проще поддерживать (DBA никакого отношения к программированию процедур не имеет — администратор); в общем случае, процедуры лучше кэшируются и пр.

Comments

[Алексей Уколов]

У DBA широкий круг обязанностей (https://ru.wikipedia.org/wiki/Администратор_баз_да...
Предполагается, что именно специалист по БД должен писать для неё триггеры и процедуры, потому что программист, не зная нюансов работы конкретной БД, может убить производительности или данные. Как правило, кто пишет схему - тот и правит её в будущем и обычно на крупных проектах это именно DBA. Но компетентный программист, конечно, тоже может этим заниматься.

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

[Алексей Уколов]

Сойдёмся на том, что простота поддержки в том или ином месте зависит на 146% от команды. Если есть сильные компетенции в области БД, то можно держать логику там (тут уже люди сами могут определить разумные пределы, раз компетенции есть). Если нет компетенций - проще поддерживать код.

Answer 2

[Алексей Уколов]

Что лучше триггер или процедура?

Каждой задаче свой инструмент, каждому инструменту свою задачу.

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

• Не всё можно сделать процедурами.
  
• Не всё оптимально делать процедурами.
  
• Процедуры может быть сложнее поддерживать - время DBA обычно дороже, чем время разработчика. Да и требования к уровню гораздо ниже в случае логики в коде - поменять какой-то несложный алгоритм можно доверить и джуниору, а вот менять схему БД его вряд ли пустят.
  
• Изменение процедур в некоторых СУБД может надолго залочить всю БД.
  

Comments

[sim3x]

+ Нет сложившихся практик (и общеиспользуемых библиотек) по юнит тестированию процедур

[Артём Каретников]

"Изменение процедур в некоторых СУБД может надолго залочить всю БД." О как... В каких и почему, интересно?

[Алексей Уколов]

Артём Каретников: я когда-то читал, что в MSSQL или Oracle с этим есть проблемы. Но если мои знания ошибочные или устаревшие, поправьте, судя по профилю, вы более компетентны в этом вопросе.

Но вообще да, формулировка "надолго залочить всю БД" кривая и скорее всего, является как минимум преувеличением.

[Артём Каретников]

Про оракл не скажу, но в MS SQL крайне рекомендуется мной везде, где это возможно, использовать процедуры. И обновление их ничего не блочит, выполняется налету.

Answer 3

[Dimonchik]

триггеры / процедуры чреваты сюрпрайзами при репликациях,
в общем-то, поэтому их и не рекомендуют использовать вообще

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

Answer 4

[Руслан Федосеев]

Программисты Оракла чешут в затылке - "а что, можно как то по другому?" :)

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

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

Таким образом принципиальная разница - кто вызывает на исполнение - сама БД (триггер), или программист извне (процедура). Никто не мешает написать процедуру, которая при добавлении платежа будет рассчитывать бонусы, пересчитывать баланс абонента, разрешать\запрещать доступ в инет, а из триггера на добавление\изменение\удаление записей таблицы вызывать эту процедуру. Таким образом можно сэкономить код - написать его один раз. В последующем сопровождать эту БД будет проще.

Реализовать логику приложения на триггерах\прооцедурах - в принципе это правильный подход, когда все детали обработки данных собраны в одном месте, во многих случаях это упростит работу с этой базой. Например, в случае того же биллинга - достаточно просто добавить запись платежа в базу и все необходимые действия будут выполнены. Т.е. упрощается разработка веб интерфейса биллинга - не надо на уровне приложения отслеживать зависимости между таблицами, пересчитывать зависимые поля и т.п.

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

Comments

[res2001]

Про программистов ораклистов - улыбнуло.

[ThunderCat]

до фразы

Реализовать логику приложения на триггерах\прооцедурах - в принципе это правильный подход,

до этой фразы полностью согласен с автором, а в цитируемом куске - не сказал бы что хранить логику на стороне хранилища - верный подход, хранилище есть хранилище. Да, триггеры нужны, процедуры тоже часто могут помочь, но писать логику в хранилище можно только до тех пор пока это относится напрямую к хранению/чтению. Дальше выносится в слой логики. На это несколько причин:
1) Язык бд специфичен и требует определенного уровня квалификации дба, которого еще найти нужно.
2) Если произойдет смена работника найти замену с подходящим уровнем может стать проблемой.
3) После разработки понадобится 2 типа разработчиков - бд и еще какой-то слой репликации, вместо 1.
4) Секурити ризон - если до базы получат доступ, на уровне логики алгоритмы не будут скомпрометированы, в противном случае весь код слит.

Плюсы тоже есть, но минусы перевешивают

[Руслан Федосеев]

ThunderCat: а я и не призываю все в процедуры. Но ведь можно ;)
А вообще - думать надо и проектировать БД.

Answer 5

[d-stream]

Это ровно как с отвертками, молотками, гвоздодерами, напильниками - все они предназначены для разных действий. Иногда конечно получается забивать напильником саморез по металлу в гипсокартон, но он фиговато держится. Что совершенно не значит что гипсокартон - плохой материал или саморезу по металлу - плохи... тем паче нельзя пенять на напильник...

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

p/s/ и да, триггеры бывают не только DML, но и DDL разных уровней + всяких специфичных видов типа event_driven, logon и т.п.

Answer 6

[Anton]

Вопрос в том, что именно вы хотите сделать. Ведь у триггера и процедуры своя технологическая направленность

Answer 7

[res2001]

Добавлю свои 5 копеек.
В свое время (90 года, раньше не в курсе), открыв любую книгу по проектированию приложений и баз данных вы бы прочитали именно такой рецепт - вся логика в б.д. на процедурах и триггерах, а клиентская часть - по сути только обеспечивает интерфейс с пользователем. Это клиент-серверная архитектура.
Сейчас же, с переходом на веб, архитектура приложения, работающего с БД стала трехзвенной, поэтому стало возможным вынести логику из БД на уровень веб-серевера/сервера приложений. Это ни плохо и ни хорошо. Просто сейчас так модно - БД просто хранилище данных, а логика вся на сервере приложений. Раньше было модно логику держать в БД.
Хотя и раньше никто не препятствовал делать трехзвенку, но она получалась искусственной и нужны были дополнительные доводы, чтоб ее реализовывать. Сейчас же трехзвенку создавать не надо - она уже есть по факту наличия веб-приложения.
Те кто не разрабатывает веб-приложения просто следуют модному течению.
По уму надо сочетать оба подхода, т.к. какие-то операции лучше реализовывать в БД, а какие-то в сервере приложений или в клиентской части.
Ну и вопрос цены, разумеется - хороший DBA (или программист БД) стоит дороже (и это более редкие звери), чем хороший веб-разрабочик.

Comments

[Fortop]

Это ни плохо и ни хорошо. Просто сейчас так модно - БД просто хранилище данных, а логика вся на сервере приложений.

res2001: Не совсем. Точнее совсем не из-за моды.
БД, в отличии от бекенда, масштабируется сложнее.
Поэтому вынос логики вычислений из БД достаточно логичен.

[d-stream]

Fortop: главное, чтобы действительно третье звено было действительно не пятым колесом... А то сейчас своего рода "трехзвенка" в виде "нифига не понимаю в sql, поэтому втащу все себе в пхп и там циклами разрулю, а потом солью клиенту полсотни жабаскриптов" - достаточно распространенная штука... Которая в итоге требует широчайшего канала между sql-сервером и web-сервером, широкого канала до клиента (ибо страничка раздута на десяток мегабайт) и компьютера помощнее (ибо свистелки-перделки требуют вычислений на клиенте как хороший рендерер) (

Answer 8

[Егор Казанцев]

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