Общаясь с разными разработчиками, я не однократно встречал абсолютно противоположные отзывы о использовании таких возможностей современных СУБД, как триггеры и хранимые процедуры. Одни отзывались о хранимых процедурах как о «серебряной пуле» при работе с базой данных, другие же, напротив, резко критиковали их.
Пообщавшись с людьми, высказывающими разные точки зрения, я постарался собрать все «за» и «против». Вот что у меня получилось:
К плюсам ХП и триггеров мои собеседники отнесли:
- Дополнительный слой инкапсуляции. ХП скрывают от разработчика клиента физическую структуру базы, давая ему возможность работать на уровне бизнес-объектов.
- Триггеры (констрейнты, домены) — отличный инструмент для поддержки целостности и непротиворечивости данных на самом близком к данным уровне. Они позволяют держать базу актуальной даже при прямом изменении таблиц в обход ХП.
- Триггеры помогают автоматически выполнять много рутинной работы (отчеты, вычисляемые значения в таблицах), автоматически актуализируют данные сразу после изменений.
- Хранимые процедуры предоставляют устойчивый интерфейс для работы с базой. При смене физической структуры внес изменения ХП (а при смене СУБД, во всяком случае на близкую по возможностям — переписал ХП и триггеры) и клиентский код работает без изменений. В данном случае не рассматривается изменение бизнес-объектов, которые конечно нужно проводить как в на базе, так и в коде.
- Документация бизнес-логики рядом с данными. Часто информационные потоки распределены по коду клиента таким образом, что их поддержка и модификация становятся очень непростым делом. В случае использования хранимых процедур и триггеров — достаточно посмотреть в их код, и вся бизнес-логика в чистом виде как на ладони.
К минусам хранимых процедур были отнесены следующие пункты:
- Ряд технических проблем в зависимости от СУБД (ограничения на функциональность ХП и триггеров, возможные проблемы с производительностью при работе с временными таблицами и т.п.)
- Сложность разработки. Отсутствие нормальной поддержки CVS для кода в базе, а не редко и хорошей среды для разработки и тестирования. Сложность работы с БД всем разработчикам команды, с большой вероятностью нужен отдельный разработчик. Наиболее часто встречающиеся способы ведения версий — это ручное ведение логов изменений структуры БД и хранимых процедур или регулярные снимки структуры базы в SQL-скрипт, который помещается под контроль версий.
- Бизнес-логика меняется чаще чем структура базы данных — поддержка версионности ещё более актуальна.
- Невозможность покрыть код в базе unit-тестами, возможные ошибки сложно отлавливаются. К примеру потеря триггера может быть обнаружена по совершенно косвенным сообщениям об ошибках.
- Использование триггеров и ХП накладывает дополнительные требования к СУБД со стороны клиента, и для систем которые призваны работать на максимальном числе платформ ХП и триггеры — непозволительная роскошь.
Мартин Фаулер в книге «Архитектура корпоративных программных приложений» называет хранимые процедуры — «оптимизационным», а не архитектурным решением. Я же думаю, что ХП и триггеры вполне могут разгрузить клиентскую часть, упростить архитектуру, и в случае, если СУБД позволяет — использование этой возможности следует иметь в виду.
Оставить комментарий