Стоит ли выносить логику работы проекта на базу (sp,trigger)?

[Rifle]

Стоит ли выносить логику работы проекта на базу (sp,trigger)?

Давно меня мучает одна мысль, вот хочу поинтересоваться у общественности, может кто уже это использует или тоже думает об использовании такого подхода.
Все больше набирает популярность MySQL >5 и все чаще его можно встретить у хостеров, в связи с чем хочется использовать все его прелести в виде работы с хранимыми процедурами, триггерами и т.д. Сейчас всю логику работы с базой храню в рнр, т-е вызываю обычные селекты, инсерты, апдейты и т.д. Вот подумываю весь sql синтаксис спрятать в хранимые процедуры базы, то есть на все действия выполняемые над данными будут соответствующие хранимые процедуры.

Вижу такие плюсы в таком подходе:
+ повышается безопасность работы с данными;
+ более правильный подход с точки зрения проектирования;
+ легче поддерживать и изменять функциональность в дальнейшем.

Минус пока только один:
- предполагаю что времени на первоначальную разработку и отладку уйдёт больше;

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

 

[fixxxer]

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

-~{}~ 09.01.08 19:25:

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

 

[basboy]

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

повышается безопасность работы с данными

если не секрет, то в чем такой подход безопаснее

более правильный подход с точки зрения проектирования

а что, до этого подход был менее правильный

легче поддерживать и изменять функциональность в дальнейшем

кому как. и как ты можешь такое говорить, если никогда так не делал. Сделай и скажешь, легче или нет.

 

[Alexandre]

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

 

[fixxxer]

я наверное чего то не понимаю. как триггер на insert/update/delete замедляет выборку?

-~{}~ 09.01.08 20:22:

кстати еще есть проблема версионности и раскладки кода =)

 

[Rifle]

Автор оригинала: basboy
если не секрет, то в чем такой подход безопаснее

Все запросы уже написаны, нельзя вмешаться в их работу... т-е sql-injection не пройдут.

-~{}~ 09.01.08 21:20:

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

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

 

[dark-demon]

о! цмс целиком на хранимых процедурах!

 

[Rifle]

Автор оригинала: dark-demon
о! цмс целиком на хранимых процедурах!

ну я не имел ввиду прям таки все
Я о том, чтоб в рнр файлах не было вообще ни одного select/insert/update/delete.
Нужны данные.. вызвал GetContent... с параметрами, точно так же на добавление новых , удаление и апдейт существующих данных.
Или все таки будет сильно громоздко.... особенно на проекты где база нужна только для хранения html кода....?

 

[dark-demon]

> чтоб в рнр файлах не было вообще ни одного select/insert/update/delete

и чего в них такого страшного?

 

[Ermitazh]

я наверное чего то не понимаю. как триггер на insert/update/delete замедляет выборку?

тоже хотелось бы узнать как триггер на insert/update/delete замедляет выборку?

 

[Rifle]

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

 

[Wicked]

Rifle
По-моему ты не те проблемы пытаешься решать с помощью sp и триггеров. Мне кажется, что ты просто не слышал про ORM.

 

[zerkms]

ещё существует такой подход, когда вся (почти вся) работа с данными переносится в субд, с целью упрощения написания различных (g)ui

 

[fixxxer]

zerkms
ну в таких случаях чаще делают аппсервер, дабы не ограничиваться хотя подход имеет право на.