Как лучше вести разработоку серверного ПО? На внешних скриптах или на триггерах?

Добрый день!

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

Сейчас передо мной стоит задача значительного расширения, и скорее всего, реинжииниринга существующего ПО. И мне нужно принципиально решить, каким путем идти. В целом вижу три пути:

1. Традиционный, когда софт разрабатывается в виде скриптов java/php/perl, не важно.
2. Перенести значительную часть логики (есть масса мелких расчетных операций) в тригеры.
3. Перенести значительную часть логики в хранимые процедуры и вызывать их либо из внешних скриптов, либо из тригерров.

Чем меня привлекает второй путь? Многие вещи, такие как логгирование, расчет прогнозов и трендов, удобнее делать отслеживание изменения событий.

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

Уже сломал все голову. Думаю, коллективный разум будет эффективнее моего одного. :) Может быть у кого-то есть опыт реализации ПО на триггерах?
  • Вопрос задан
  • 3600 просмотров
Пригласить эксперта
Ответы на вопрос 6
@rPman
Если вы будете единственным разработчиком ПО я рекомендую не выбирать путь с триггерами и реализации логики на стороне БД. Так как проблем создадите себе много а плюсы этого метода — не прочувствуете.

Разработка всей или части логики на стороне БД удобна в случаях когда нужно 'разделять и властвовать', когда удобно, из соображений надежности разработки и минимизации ошибок (например нарушений логической структуры БД), выделить и оформить соответствующий код на стороне БД таким образом, чтобы логику структуры БД невозможно было нарушить никакими ошибками на стороне приложения (php/java/..). Собственно изначально за кодом на стороне БД эта функция и закреплялась — контроль над целостностью БД.

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

Ну и конечно, у серверных приложений доступно на выбор огромное количество уже готовых решений, библиотек, фреймворков… которых может просто не оказаться для языка хранимых процедур вашей БД.
Ответ написан
EugeneOZ
@EugeneOZ
А если заказчик захочет поменять БД, что Вы ему скажете? «Извините, тут надо пару человеко-месяцев на адаптацию триггеров»? :)
Триггеры и хранимые процедуры это ад и содомия в вопросах поддержки и развития.
Ответ написан
@hippoage
Традиционный способ не случайно традиционен. Нужны веские доводы, чтобы им не пользоваться.

Разработка в БД даже после установки/настройки/адаптации окружения для разработки все равно дольше, чем разработка обычных программ. Так же появляются дополнительные архитектурные ограничения. Единственный плюс — это увеличение скорости сложных выборок.
Ответ написан
@gleb_l
Я в основном рассматриваю триггеры, как костыли при модернизации уже готовой системы — например, добавить аудит изменений данных, апдейты полей в FK-таблицах при отклонениях от нормальной формы в угоду перформансу итд. Изначально на них закладываться я бы не стал, кроме случаев, когда например необходима железная защита от неадекватных действий слоя приложения критичных данных (скажем удаление финансовых транзакций определенного типа, которые ни при каких условиях не могут быть удалены). Всю логику на триггерах крайне желательно описывать и это описание прикладывать к БД и не забывать обновлять в репозитории.
Теперь насчет холивара насчет размещения бизнес-логики — в БД или в слое приложения? Как всегда, самый оптимальный с точки зрения производительности вариант — паллиативный. Он же самый дорогой и трудноподдерживаемый. Но по-другому не бывает — хотите выжать максимум из системы — используйте сложные структуры. Я стараюсь безусловно прятать логику в SP, если:
а) операция критична с точки зрения бизнес-целостности ключевых данных
б) операция производит или манипулирует большим количеством связанных данных и/или требует специфических опции БД (локи, частичные откаты, try/catch итд) для эффективного выполнения.
в) знания о бизнес-модели и процессах в проектируемой системе есть только у бакендщика, а фронтенд-разработчики — просто рисователи форм. Иногда бывает быстрее, собрав требования с заказчика, реализовать по ним бронебойный бакенд, чем рассказать остальным как это должно работать, а потом отлаживать всем миром все по функционалу и производительности.
В любом случае, логику, частично реализованную в БД, хорошо бы детально описывать и описание класть в репозиторий. Желательны и тестирующие логику скрипты.
Ответ написан
Комментировать
@ITguru
Не так давно читал срач примерно на эту тему тут
Ответ написан
@rozhik
Используйте комбинированный подход. Где удобнее 1 — тогда 1, где 2 — тогда 2 итп. Старайтесь делать в приоритете 2. Не занимайтесь параноей, и не старайтесь всё переложить на базу.
Логически правильнее второй подход. Но очень часто 1 подход на много более выгоден с точки зрения времени разработки или ресурсоёмкости.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы