Повторное использование кода SQL Server с помощью хранимых процедур - хорошая или плохая практика?

Question

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

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

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

В наши дни я считаю, что повторное использование кода не обязательно повышает удобство сопровождения впроектирование базы данных.

Мне нужна информация от более опытного разработчика SQL Server, чем я?

Заранее спасибо.

Answer 1

Отказ от ответственности: это не «не используйте хранимые процедуры - думайте о детях!»пост, и я не собираюсь разжечь пламенную войну.Я просто предполагаю, что повторное использование кода проще и, возможно, больше подходит для определенных ситуаций и платформ, чем для других.

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

Однако, как и все, можно ошибиться (с властью приходит ответственность, бла-бла-блабла).

В большинстве современных языков программирования относительно просто повторно использовать код, либо написав функции, либо даже создав целые фреймворки, которые можно использовать снова и снова.Однако в T-SQL это сложно, потому что у вас меньше вариантов.Хранимые процедуры могут это сделать, но вы уже видели, как они могут быть неловкими.

Мое личное предпочтение - не допускать бизнес-логику в базу данных.Это означает, что я не использую представления, UDF, sprocs и т. Д. (Если только после профилирования производительности мы не думаем, что сможем ускорить что-то с помощью этих методов), а вместо этого сохраняю это в своем коде приложения.Это часто вызывает мысли о «слое бизнес-логики», но есть разные варианты этого, так что это, вероятно, неправильно.Это, конечно, не код непосредственно за обработчиками нажатий кнопок пользовательского интерфейса и т. Д.

Я стремлюсь ограничить базу данных хранением и извлечением данных, потому что это то, в чем они действительно хороши.Мы все знаем, насколько неуклюжим и устаревшим T-SQL может быть язык (например, обработка исключений, развертывание, курсоры и т. Д.).Быть независимым от базы данных совершенно невозможно, если ваше приложение записано в саму базу данных, и вы также не можете масштабировать свое приложение, потому что база данных является приложением.Если у вас есть эта бизнес-логика в коде приложения, ее можно гораздо легче масштабировать.

В этом случае «бизнес-логика» - это запросы и преобразования, используемые для генерации ваших отчетов, и я бы изучил, как онаможет быть возможно повторно использовать код в вашем средстве создания отчетов / коде, прежде чем рассматривать другие варианты.

Answer 2

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

Присоединение представлений к представлениям может работать нормально или может привести к неэффективности в зависимости от их определения.

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

Answer 3

Основная цель повторного использования кода, IMO, состоит в том, чтобы разбить монолитные программы на более легкие для понимания и более легкие в обслуживании части.Разделение труда не должно быть своеобразным - личная причудливая идея порядка одного человека.Искусство создания библиотеки вспомогательных функций в значительной степени является социальным искусством - вы должны определить понятный API, который является последовательным в своем подходе.Вы не хотите, чтобы программисты, которые следуют за вами, проклинали вас заочно.Вы хотите, чтобы они поблагодарили вас за ясность и полезность вашего дизайна.

@ Нил Барнвелл: Я не вижу проблем с встраиванием бизнес-правил в базу данных.Триггеры и хранимые процедуры могут выполнять эту роль также хорошо, если не лучше, чем средний уровень или клиентский код.Конечно, у вас должны быть программисты, которые освоили язык программирования в базе данных, T-SQL или PL / SQL или что-то еще.