Несколько недель назад один из пользователей, который сравнительно недавно начал работать с SQL Server, задал мне странный вопрос. "Я прочитал, - сказал он, - что никогда не следует использовать хранимые процедуры при проектировании приложений SQL Server. Совет помещен на домашней странице обладателя сертификата Microsoft MVP, и, полагаю, он должен быть справедлив. Каково ваше мнение? Следует ли отказаться от хранимых процедур в разрабатываемом нами приложении?"
Тем не менее, я был заинтригован тем, что, по словам клиента, совет исходил от обладателя сертификата Microsoft MVP (члена сообщества разработчиков, а не SQL Server MVP). Аналогичные публикации встречаются и на других сайтах, посвященных разработке на платформе Microsoft. Я прочитал статьи, на которые ссылался мой клиент, и к своему удивлению, обнаружил, что согласен со многими аргументами в пользу отказа от хранимых процедур.
Однако я не склонен думать, что следует "избегать процедур как чумы" при разработке приложений SQL Server.
В данной статье недостаточно места, чтобы рассмотреть все аргументы "за" и "против", и выводы, которые я считаю неверными. Главная цель данной публикации состоит не в том, чтобы твердо отстаивать использование процедур (конечно, сам я применяю их постоянно). Я хотел бы лишь предостеречь от следования техническим советов без понимания всех последствий.
Мне хочется рассказать о проекте, над которым я работал несколько лет назад, когда набирал популярность "динамичный" стиль проектирования. Это поможет разъяснить мою точку зрения. В ходе работы над проектом мне пришлось устранять проблему, которая отрицательно влияла на быстродействие и, как выяснилось, была связана с динамичным, объектно-ориентированным подходом к разработке приложения по подсчету корзины покупок. Программисты подготовили простую в использовании и обслуживании библиотеку для управления корзиной.
К сожалению, они слишком увлеклись "объектно-ориентированным" подходом. Каждый элемент (например, офисный стул) имел многочисленные свойства (цвет, высота и т.д.), и для получения данных, связанных с каждым свойством каждого элемента требовалось обращение к серверу. На главной поисковой странице приложения часто находилось до 20 элементов, и у каждого элемента бывало до 20 свойств. Поэтому для обновления единственной страницы часто требовалось более 400 обращений к серверу.
Естественно, приложение масштабировалось плохо. Базовая концепция программистов была разумна, но они предпочли форму функции. Изящная на первый взгляд архитектура прикладного уровня была построена без учета влияния на уровне базы данных.
Доводы в Web-публикациях, которые читал мой клиент, достаточно обоснованы. Однако опасно сводить любой набор рекомендаций к безапелляционному выводу, особенно если отсутствует четкое понимание последствий применения правила.
Это главная мысль, которую я хотел подчеркнуть в статье. Ответ на любой вопрос о производительности или архитектуре лучше всего начинать с фразы: "В зависимости от обстоятельств". Затем необходимо исследовать факты и определить оптимальное решение, используя любые приемы, подходящие в данных условиях. Не стоит советовать: "Следует поступать только так". И опасно следовать рекомендациям, не понимая всех последствий. Известно ли, какие результаты принесет полный отказ от хранимых процедур раз и навсегда? До тех пор, пока не удастся принять информированного и квалифицированного решения, постарайтесь удержаться от опрометчивых шагов.